Guido van Rossum wrote:

The base of the Exception hierarchy happens to be a classic class.
But why are they "required" to be classic?

More to the point, is this a bug, a missing feature, or just a bug in
the documentation for not mentioning the restriction?



It's an unfortunate feature; it should be mentioned in the docs; it should also be fixed, but fixing it isn't easy (believe me, or it would have been fixed in Python 2.2).

To be honest, I don't recall the exact reasons why this wasn't fixed
in 2.2; I believe it has something to do with the problem of
distinguishing between string and class exception, and between the
various forms of raise statements.

I think the main ambiguity is raise "abc", which could be considered
short for raise str, "abc", but that would be incompatible with except
"abc". I also think that the right way out of there is to simply
hardcode a check that says that raise "abc" raises a string exception
and raising any other instance raises a class exception. But there's a
lot of code that has to be changed.

It's been suggested that all exceptions should inherit from Exception,
but this would break tons of existing code, so we shouldn't enforce
that until 3.0. (Is there a PEP for this? I think there should be.)



There's actually a bug open on the fact that exceptions can't be new-style classes:


https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470

I added some comments to try to stir it up but there ended up being a lot of confusion and I don't think I helped much. The problem is that people want to solve the larger issues (raising strings, wanting to force all exceptions to be new-style, etc) but those all have long-term solutions, while the current bug just languishes.

robey

_______________________________________________
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

Reply via email to