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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com