[Python-Dev] Proposed resolutions for open PEP 343 issues

Eric Nieuwland eric.nieuwland at xs4all.nl
Thu Oct 27 14:45:54 CEST 2005


Michael Chermside wrote:

> Guido writes:
>> I find "AttributeError: __exit__" just as informative.
>
> Eric Nieuwland responds:
>> I see. Then why don't we unify *Error into Error?
>> Just read the message and know what it means.
>> And we could then drop the burden of exception classes and only use 
>> the
>> message.
>> A sense of deja-vu comes over me somehow ;-)
>
> The answer (and there _IS_ an answer) is that using different exception
> types allows the user some flexibility in CATCHING the exceptions. The
> discussion you have been following obscures that point somewhat because
> there's little meaningful difference between TypeError and
> AttributeError (at least in well-written code that doesn't have
> unnecessary typechecks in it).

Yep. I too would like to have 'SOME flexibility in catching the 
exceptions' meaning I'd like to be able to catch TypeErrors and 
AttributeErrors while not catching what I call ProtocolErrors. The 
simple reason is that in most of my apps TypeErrors and AttributeErrors 
will depend on the runtime situation, while ProtocolErrors will mostly 
be static. So I'll debug for ProtocolErrors and I'll handle runtime 
stuff.

> If there were a significant difference between TypeError and
> AttributeError then Nick and Guido would have immediately chosen the
> appropriate error type based on functionality rather than style, and
> there wouldn't have been any need for discussion.

I got that already. To me it means one of them may be a candidate for 
removal/redefinition.

> Oh yeah, and you can also put extra info into an exception object
> besides just the error message. (We don't do that as often as we
> should... it's a powerful technique.)

Perhaps that needs for propaganda then. I won't dare to suggest 
syntactic sugar ;-)

--eric



More information about the Python-Dev mailing list