On Sat, Feb 22, 2014 at 1:50 AM, Antoine Pitrou <[email protected]> wrote:
> On Sat, 22 Feb 2014 00:28:01 +1000
> Nick Coghlan <[email protected]> wrote:
>>
>> Neither of these objections addresses the problems with the status quo,
>> though:
>>
>> - the status quo encourages overbroad exception handling (as
>> illustrated by examples in the PEP)
>
> I don't get this. Using the proper exception class in a "try...except"
> suite is no more bothersome than using the proper exception class in
> this newly-proposed construct.
Overbroad exception handling comes in two ways. One is simply catching
Exception or BaseException when a narrower class would be better, and
that's not addressed by this PEP (except insofar as it does not have a
bare "except:" syntax, and so it forces you to at least be explicit
about catching BaseException). The other is this:
try:
f(x[i])
except IndexError:
f(default)
Translating that into this form:
f(x[i] except IndexError: default)
means that an IndexError thrown inside f() will not be caught. While
it is, of course, possible to write that currently:
try:
arg = x[i]
except IndexError:
arg = default
f(arg)
it's that much less readable, and as evidenced by several examples in
the standard library (some of which are in the PEP, and a few more can
be found in my associated collection [1]), it's common to short-cut
this. By providing a clean and convenient syntax for catching an
exception in just one small expression, we encourage the narrowing of
the catch front.
ChrisA
[1] https://github.com/Rosuav/ExceptExpr/blob/master/examples.py
_______________________________________________
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
