exception question

[Gonçalo Rodrigues]

Hi,

For error processing I found convenient maintaining a dictionary where
the keys are exception *classes* and the values are callables. Of
course, for this to work, exception classes have to be hashable which
I happily found that they were. So my question is, can I count on this
behaviour? Or is this behaviour I should not count on? (I found
nothing on the docs about it, thus the question).

With my best regards,
G. Rodrigues

 

[Peter Otten]

For error processing I found convenient maintaining a dictionary where
the keys are exception *classes* and the values are callables. Of
course, for this to work, exception classes have to be hashable which
I happily found that they were. So my question is, can I count on this
behaviour? Or is this behaviour I should not count on? (I found
nothing on the docs about it, thus the question).

(No answer to your question)

import sys

class MyException(Exception):
def __init__(self, msg, handler):
Exception.__init__(self, msg)
self.handler = handler

try:
raise MyException("yup", lambda: sys.stdout.write("call it sleep\n"))
except MyException, e:
e.handler()

Would that eliminate the need for a dictionary?

Peter

 

[Bruno Desthuilliers]

Hi,

For error processing I found convenient maintaining a dictionary where
the keys are exception *classes* and the values are callables. Of
course, for this to work, exception classes have to be hashable which
I happily found that they were. So my question is, can I count on this
behaviour? Or is this behaviour I should not count on? (I found
nothing on the docs about it, thus the question).

Did you try ? I guess you didn't :

Python 2.2.2 (#2, Feb 5 2003, 10:40:08)
[GCC 3.2.1 (Mandrake Linux 9.1 3.2.1-5mdk)] on linux-i386
Type "help", "copyright", "credits" or "license" for more information.

>>> class TestError(Exception): pass ....
>>> d = {TestError: "TestError"}
>>> d

>>> l = [1,2,3]
>>> d = {l : "truc"}

Traceback (most recent call last):

BTW, it seems that classes are hashable !-)

Bruno

 

[Gonçalo Rodrigues]

(No answer to your question)

import sys

class MyException(Exception):
def __init__(self, msg, handler):
Exception.__init__(self, msg)
self.handler = handler

try:
raise MyException("yup", lambda: sys.stdout.write("call it sleep\n"))
except MyException, e:
e.handler()

Would that eliminate the need for a dictionary?

Yup, I did though of of a scheme like that before -- It's my fall back
solution in case I should not count on the fact that exception classes
are hashable.

Thanks anyway,
G. Rodrigues

 

[Aahz]

For error processing I found convenient maintaining a dictionary where
the keys are exception *classes* and the values are callables. Of
course, for this to work, exception classes have to be hashable which
I happily found that they were. So my question is, can I count on this
behaviour? Or is this behaviour I should not count on? (I found
nothing on the docs about it, thus the question).

If it's not documented, you can't count on it. There's no intrinsic
reason exception classes would be made unhashable, *but* classes become
unhashable as soon as they implement __cmp__() or __eq__() *and* they
fail to implement __hash__(). So if someone ever asks to compare
exceptions, it could be an issue.

You may want to bring this issue up on python-dev.

 

[Alex Martelli]

If it's not documented, you can't count on it. There's no intrinsic
reason exception classes would be made unhashable, *but* classes become
unhashable as soon as they implement __cmp__() or __eq__() *and* they
fail to implement __hash__(). So if someone ever asks to compare
exceptions, it could be an issue.

A new-style class would NOT become unhashable by implementing __eq__
w/o __hash__, although its INSTANCES would (but Gonçalo is clearly
indicating that he cares about classes, not instances). Unfortunately
exception classes are old-style, so they'd be subject to the darned
old confusion between class and instance. HOWEVER, one might hope
that if ever standard exception classes ARE changed in a way that is
not backwards compatible, by adding __eq__ &c, then at the same time
they might be made new-style classes, which would in any case have
much lesser potential for old-code breakage.

You may want to bring this issue up on python-dev.

Good suggestion -- but I'd further suggest the class-vs-instance
and old-vs-new classes distinctions be clearly kept in mind when
so doing.


Alex

 

[Bengt Richter]

Hi,

For error processing I found convenient maintaining a dictionary where
the keys are exception *classes* and the values are callables. Of
course, for this to work, exception classes have to be hashable which
I happily found that they were. So my question is, can I count on this
behaviour? Or is this behaviour I should not count on? (I found
nothing on the docs about it, thus the question).

Would the class name strings work for you, to avoid the issue?

Regards,
Bengt Richter