[Python-Dev] Proposed resolutions for open PEP 343 issues
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
>> 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
> 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
> 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 ;-)
More information about the Python-Dev