homepage

I have discovered the following behaviour in 2.5, which I cannot explain:
>>> try:
... raise ValueError("foo")
... except object:
... print "aiee!"
... 
Traceback (most recent call last):
 File "<stdin>", line 2, in <module>
ValueError: foo
>>> sys.version
'2.5.1 (r251:54863, Jan 23 2008, 16:53:41) \n[GCC 4.2.2 (Gentoo 4.2.2
p1.0)]'
>>> isinstance(ValueError("foo"), object)
True
At first I thought I misunderstood something about exceptions, but the
wording of the try-statement leads me to believe that this should work.
ValueError is a subclass of object and thus, I think, should be a match,
thus catching the exception.
I realize that all exceptions should inherit from Exception
(BaseException?), but for the sake of consistence, shouldn't "except
object" catch *anything* in python 2.5? I.e. be the equivalent of "except:".
Is this a bug? If so, should this be fixed?

Py3k behavior seems to be better:
Python 3.0a2+ (py3k:61137M, Feb 29 2008, 15:17:29) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
>>> try: 
... raise ValueError("foo")
... except object:
... pass
... 
Traceback (most recent call last):
 File "<stdin>", line 3, in <module>
TypeError: catching classes that do not inherit from BaseException is 
not allowed
Something needs to be done for 2.6: at the minimum a warning should be 
issued under -3 option.

See PEP 352. Currently this is slated for python 2.8. Perhaps the
schedule should be sped up a bit in light the current release schedule.
 Brett, any comments? We should add all the warnings from PEP 352 with
the -3 flag to 2.6.

On Sat, Mar 15, 2008 at 5:30 PM, Neal Norwitz <report@bugs.python.org> wrote:
>
> Neal Norwitz <nnorwitz@gmail.com> added the comment:
>
> See PEP 352. Currently this is slated for python 2.8. Perhaps the
> schedule should be sped up a bit in light the current release schedule.
> Brett, any comments? We should add all the warnings from PEP 352 with
> the -3 flag to 2.6.
We could add warnings for everything slated to go in 3.0. As for 2.x,
I don't think tossing in warnings for 2.6 is good, but it could be
made a PendingDeprecationWarning, with 2.7 being full
DeprecationWarning.

I thought some more about this issue and the current behavior seems 
wrong and potentially dangerous. Consider the following code:
class x: 
 pass 
class y(x): 
 pass 
try: 
 raise y 
except y: 
 print "a" 
except: 
 print "b" 
It prints 'b'. Now, suppose in preparation for 3.0 transition someone 
adds "__metaclass__ = type" to the module with that code. The result: 
it prints 'a'. Since the difference in behavior is in error handling 
code, which in my experience is often not thoroughly tested, the bug 
introduced by a seemingly innocuous move from old to new style classes 
is likely to trigger in the worst possible moment. (For example a wrong 
roll-back logic is applied after a failed database commit.)
My understanding is that the current logic of bypassing the subclass 
check in PyErr_GivenExceptionMatches in the case of new style class 
which is not a subclass of BaseException, is designed to support string 
exceptions. Maybe a better choice would be to exclude only string 
subclasses from a subclass check.
I will submit a patch if others agree that this approach is worth 
considering.

Actually, if you go back to 2.4, before BaseException even existed, a
try/except with a new-style class in the 'except' clause was also
possible. Actual enforcement of what can be in an 'except' clause is a
new thing added by PEP 352. Suddenly making this any more than a warning
will be too aggressive. And the PEP already stated the transition path.
As I said, I have no problem speeding up PendingDeprecationWarnings in
2.6 and adding Py3K warnings now, but anything more severe in 2.6 (i.e.,
a DeprecationWarning flat-out) would require python-dev approval.

I am commenting on issue2371 patch here, so that I does not get lost in
a non-showstopper issue. Taek, please reattach your patch here when you
get a chance.
With the additional -3 logic, code duplication between tuple and
non-tuple case becomes unbearable. I suggest separating both string and
subclass checks in a separate function.

There is also a subtle bug in the issue2371 patch:
$ cat x.py
try:
 raise ValueError
except ((ValueError,),):
 pass
$ ./python -3 x.py
x.py:3: DeprecationWarning: catching classes that do not inherit from
BaseException is not allowed in 3.x.
 except ((ValueError,),):
I am not sure if it would be acceptable to move warnings to
PyErr_GivenExceptionMatches, but if not, the checking logic should
reproduce PyErr_GivenExceptionMatches' recursive behavior.

Correction for msg63584: the old/new style difference example should read
"""
class x: 
 pass 
class y(x): 
 pass 
try: 
 raise y 
except y: 
 print "b" 
except: 
 print "a"
"""
As written it prints 'b', but with __metaclass__ = type, it prints 'a'.
In msg63584 I got 'a' and 'b' mixed up.
On python-dev, Guido responded that the result should be the same
regardless of the metaclass:
http://mail.python.org/pipermail/python-dev/2008-March/077713.html 

I finally figured this out. The try/except statement is a complete red
herring; the problem is in the raise statement. The behavior is the
same in 2.4, 2.5 and 2.6, even though Exception is a classic class in
2.4 and a new-style class in 2.5 and 2.6.
The rules are relatively straightforward, and explain all observations,
once you realize that attempting to raise something that is not allowed
raises a TypeError:
- you can raise strings (except in 2.6 -- see footnote)
- you can raise any classic class
- you can raise any class that derives from [Base]Exception
(That last rule is subtle, due to standard exceptions changing from
classic to new-style in 2.5.)
I do not believe that there is anything wrong in this set of rules, and
would object to a change that would allow raising any new-style class in
2.6, since this would be a temporary relaxation of the rules, whereas in
3.0 we will be significantly *tightening* the rules!
PEP 352 states that in Python 2.7 we will deprecate raising exceptions
that don't derive from BaseException; in 2.8 we will deprecate catching
those; and 2.9 we may deprecate __getitem__ on exceptions. This was
written before 3.0 was really planned; IMO we should have "-3" warnings
for all these things in 2.6. This implies that "except object:" will
get a -3 warning -- but not a deprecation warning.
I do recommend that these rules be documented more clearly.
(Footnote: if I read PEP 352 carefully, I don't believe raising strings
was supposed to be disallowed before 3.0. I'm not sure it's worth
reverting this though.)

What is the pronouncement on the OP's issue? While "except object:" is 
still valid, should it catch anything?

"except object:" will continue to be a no-op, if only for compatibility.
With -3 it will issue a warning (I just checked this in, from
issue2371). With -3 -Werror it will be an error.
We still need patches to issue -3 warnings for:
- raising exceptions that don't derive from BaseException
- __getitem__ or __getslice__ on exception instances

On Mon, Mar 17, 2008 at 11:00 PM, Guido van Rossum
<report@bugs.python.org> wrote:
..
> - raising exceptions that don't derive from BaseException
See patch at issue2341.

On Mon, Mar 17, 2008 at 11:00 PM, Guido van Rossum
<report@bugs.python.org> wrote:
> We still need patches to issue -3 warnings for:
> - __getitem__ or __getslice__ on exception instances
>
I've opened a separate issue for this (see issue2379). I believe this
issue can now be closed.

Thanks!