[Python-ideas] Proposal: Abolition of bare except clauses

Andrew Barnert abarnert at yahoo.com
Sat Apr 11 14:25:44 CEST 2015


On Apr 11, 2015, at 04:29, Chris Angelico <rosuav at gmail.com> wrote:
> 
> A bare "except:" clause catches any exception. As of Python 3.0, this
> can be spelled more explicitly as "except BaseException:", and AFAIK
> the only difference between the two is that someone might rebind
> BaseException.
> 
> String exceptions were abolished during the 2.x line, without causing
> major upheaval.

I couldn't remember when this happened, so I look at the docs... But 2.7 (https://docs.python.org/2.7/reference/executionmodel.html#exceptions) still say "Exceptions can also be identified by strings, in which case the except clause is selected by object identity." Do the docs need to be fixed?

Meanwhile, in the C API (https://docs.python.org/2.7/c-api/exceptions.html#string-exceptions), it says "Changed in version 2.6: All exceptions to be raised or caught must be derived from BaseException." I think that one is correct, but until I sit down at a bigger screen where I can browse the source or run an interpreter, I'm not sure.

> The deprecation and ultimate abolition of the bare
> except syntax would have less consequence than that, as it would
> merely require a mechanical transformation to "except BaseException:",
> without needing any corresponding changes at raise site.
> 
> Pros:
> * Remove the attractive nuisance of "hmm, my code's throwing an error
> that I don't recognize, I'll use try/except" and just catching
> everything.

But if you just teach people "spell that as except BaseException:" (or, more likely, "... as except Exception:"), it's still the exact same attractive nuisance. And, because "except:" is almost always a red flag in novice code, but "except Exception:" is occasionally reasonable, you're making it a tiny bit harder to spot the mistake when helping novices, without actually fixing it.

(Of course requiring an "as" clause would solve all of this, but nobody wants that...)

> * Eliminates the edge case wherein "except:" and "except ():" are
> almost diametrically opposite in meaning. Not often a concern, but
> we've just had a lengthy thread on python-list discussing this. It's
> generally agreed that an empty tuple has to be interpreted as catching
> nothing, but the false parallel with an empty clause is problematic.
> 
> Cons:
> * May make it harder to write Py2/Py3-compatible code. In Py2,
> "except:" will catch old-style-class exceptions.

If the C API docs are right and exceptions must be derived from
BaseException even in 2.6, they can't be old-style class instances in the first place. (And if anyone's trying to write 2.5/3.x code, they still have to deal with string exceptions, not to mention that they can't get the value of any exceptions they handle, so they've got much bigger problems.)

Even if that's not right, what problems do old-style classes cause that new-style-but-not-BaseException-derived classes don't?

> * Any removal of any feature can cause examples and published code to break.
> 
> Undecided:
> * Forcing everyone to look at the code that uses "except:" means extra
> work to upgrade Python, but it might mean they notice a problem
> somewhere. Maybe it should be "except Exception", or maybe something
> even more specific. Is this a pro or a con?
> 
> Thoughts?
> 
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150411/1250a89e/attachment-0001.html>


More information about the Python-ideas mailing list