Raising objects

[Alex Martelli]

Michael Chermside wrote:

> Alex writes:
>> I would explain my desiderata differently: raising any instance
>> of NewException raises it; raising any subclass of NewException
>> instantiates it (optionally with the provided argument[s]) and
>> raises the resulting instance.
> 
> Hmm... I'd agree with this EXCEPT that there's currently an
> advantage to raising classes instead of instances: the interpreter
> may behave AS IF the instance were created and thrown, but
> (if I understand the behavior correctly) it doesn't actually
> create the object.

Hmmm, could you provide an example?  As I see things:

>>> class ohya(Exception):
...   def __init__(*args):
...     print 'created!'
...     Exception.__init__(*args)
...
>>> raise ohya
created!
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
__main__.ohya
>>>

...the creation does seem to be taking place just as it should.
What makes you understand it actually isn't?


> Not that performance is the the be-all and end-all of design, nor
> is exception handling the most important place to optimize, but
> it's kinda neat that it saves this unnecessary object creation
> JUST SO LONG AS it goes ahead and creates the object if you ever
> do anything which would access that object.

You mean there's something in the interpreter detecting that
class ohya has an __init__ and therefore instantiating it, but
that it wouldn't be instantiated if it had no __init__?  I
can't see anything like that in the C code, but I may be
missing something.  Anyway, even if I _AM_ missing something,
I don't really see anything "kinda neat" in such deep, dark
black magic -- what WOULD the occasions be where you "don't do
anything" (neither handle the exception nor let it propagate?
if you handle it, isn't the instance in sys.last_value...?) --
it seems potentially worth more confusion than advantage.


Alex