New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exception cannot be new-style class #36116
Comments
[magnus@gills magnus]$ python2.2
Python 2.2 (#1, Jan 26 2002, 14:27:24)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class foo(object):
... pass
...
>>> raise foo()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: exceptions must be strings, classes, or instances, not foo
>>> |
Logged In: YES Interesting. I think we need to deprecate, then remove |
Logged In: YES Martin, I think the attached patch is sufficient. It checks If this patch makes sense to you, I'll flesh it out with |
Logged In: YES I thought the agreement was that this is not a bug: You |
Logged In: YES I don't realize there was agreement on this. (I didn't |
Logged In: YES Sorry, HEAPTYPE is not the proper way to check for a At best there's agreement that it's not worth trying to fix If your module declares its exceptions as deriving from Here's another idea for a patch: a new-style class is |
Logged In: YES What about the following patch (diff.txt): It allows new style objects as exceptions and makes catching With this patch subinstances of str become raisable and will And As soon as Exception is a new style class we could limit the |
Logged In: YES test.py is a little script that executes various test cases. |
Logged In: YES Just to make things even more interesting, the current It seems to me that the very first thing that should be |
Logged In: YES Reproduced the bug in Py2.3. I think that this is a bug, at The moment we say that they "must" derive from Exception, |
Logged In: YES This caused me an hour of debugging a few nights ago. When class MyException (Exception, object):
pass does not work! The interpreter (2.3) refuses to let you Please fix this for 2.4! |
Logged In: YES Whatever the solution to this problem, it is for sure that |
Logged In: YES Let me try to rephrase the problem so that it's obvious that 'type(e)' on an exception will not work in 2.3, and cannot |
Logged In: YES This statement, as literally made, is incorrect: >>> class X(Exception):
... pass
...
>>> e=X()
>>> type(e)
<type 'instance'>
>>> raise e
Traceback (most recent call last):
File "<stdin>", line 1, in ?
__main__.X: <__main__.X instance at 0x401f2b4c> In this example, type(e) works, and x is an object which has Even if I interpret your statement more literally (i.e. that As for why it is a new feature: it currently doesn't work, Notice that it is very difficult to implement this feature, A clean solution would be to deprecate string exceptions in Please do read the entire thread of this RFE. |
Logged In: YES (I wish we could do this in email instead of cluttering up Forget about throwing non-Exception-based objects: it's a Bottom line: This subclass of Exception can not be raised class MyException (Exception, object): pass pje's comment below from (2002-07-11 13:12) is a nice |
Logged In: YES rev. 42711 (PEP-352 implementation) made built-in exceptions |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: