Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > exception question

Reply
Thread Tools

exception question

 
 
Gonšalo Rodrigues
Guest
Posts: n/a
 
      08-31-2003
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
 
Reply With Quote
 
 
 
 
Peter Otten
Guest
Posts: n/a
 
      08-31-2003
Gonšalo Rodrigues wrote:

> 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
 
Reply With Quote
 
 
 
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      08-31-2003
Gonšalo Rodrigues wrote:
> 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:0
[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

{<class __main__.TestError at 0x80a66bc>: 'TestError'}
>>> l = [1,2,3]
>>> d = {l : "truc"}

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: list objects are unhashable
>>>


BTW, it seems that classes are hashable !-)

Bruno

 
Reply With Quote
 
Gonšalo Rodrigues
Guest
Posts: n/a
 
      08-31-2003
On Mon, 01 Sep 2003 00:14:13 +0200, Peter Otten <(E-Mail Removed)>
wrote:

>Gonšalo Rodrigues wrote:
>
>> 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?


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

 
Reply With Quote
 
Aahz
Guest
Posts: n/a
 
      09-01-2003
In article <(E-Mail Removed)>,
Gonšalo Rodrigues <(E-Mail Removed)> wrote:
>
>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.
--
Aahz ((E-Mail Removed)) <*> http://www.pythoncraft.com/

This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz
 
Reply With Quote
 
Alex Martelli
Guest
Posts: n/a
 
      09-01-2003
Aahz wrote:

> In article <(E-Mail Removed)>,
> Gonšalo Rodrigues <(E-Mail Removed)> wrote:
>>
>>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.


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

 
Reply With Quote
 
Bengt Richter
Guest
Posts: n/a
 
      09-01-2003
On Sun, 31 Aug 2003 22:22:15 +0100, Gonšalo Rodrigues <(E-Mail Removed)> wrote:

>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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Exception of type 'System.Web.HttpUnhandledException' wasthrown.Exception has been thrown by the target of an invocation.System.WebSystem.Exception jobs ASP .Net 1 11-16-2007 05:57 PM
while executing my client program i get the exception javax.naming.LinkException: [Root exception is javax.naming.LinkException: [Root exception is javax.naming.NameNotFoundException: remaining if plz anybody know how to solve this problem then mahesh Java 0 03-08-2007 12:26 PM
Throw Exception Vs Throw New Exception Kerri ASP .Net 2 10-27-2003 02:13 PM
Re: bizaar exception that isn't really an exception jeff ASP .Net 3 06-26-2003 01:02 PM
Re: bizaar exception that isn't really an exception jeff ASP .Net 0 06-24-2003 12:46 PM



Advertisments