[Python-ideas] syntax to continue into the next subsequent except block
yselivanov.ml at gmail.com
Sun Sep 16 19:16:34 CEST 2012
On 2012-09-15, at 10:20 PM, Cameron Simpson <cs at zip.com.au> wrote:
> On 15Sep2012 09:15, Paul Wiseman <poalman at gmail.com> wrote:
> | On 14 September 2012 03:32, Nick Coghlan <ncoghlan at gmail.com> wrote:
> | > On Fri, Sep 14, 2012 at 11:52 AM, Stephen J. Turnbull
> | > <stephen at xemacs.org> wrote:
> | > > ISTR there were discussions of "qualified except" clauses here maybe
> | > > 6mo to 1yr ago? That is, they'd look something like
> | > > try:
> | > > operation()
> | > > except IOError as err if err.errno == 2:
> | > > Again ISTR that this got spiked for some reason, but maybe it will be
> | > > of use to the OP in formulating his next idea. Sorry for the lack of
> | > > precise reference.
> | >
> | > They were one of the ideas discussed when Antoine was writing PEP
> | > 3151. As I recall, nobody could think of any good use cases that
> | > didn't involve errno checking, and PEP 3151 provides a far more
> | > elegant (and cross-platform) solution to most problems that require
> | > errno checking in versions prior to 3.3.
> | >
> | Ah I didn't know about that, maybe I chose a bad example with IOError.
> | The reason that got me thinking is I had to handle specific
> | S3ResponseErrors from boto.
> | the S3ResponseError exception class has a code attribute (or errorcode, i
> | forget exactly).
> I have to say I find this supportive. I think the reason that there were
> no use cases that don't involve errno is that most exceptions don't
> provide fine grained failure information. IOError/OSError's errno is
> the main exception.
> Personally I think it is a shame that exceptions are generally so
> raise ValueError("arbitrary prose here")
So you want to write code like:
except ValueError as ex if 'foo is wrong' in ex.args:
This thread started with IOError and its errno attribute, and for those
exact cases I find 'except .. if' approach quite useful. But now, in
3.3 with PEP 3151 we have a much more granular exceptions tree, so instead
except IOError as ex if ex.errno == errno.ENOENT:
you will write:
except FileNotFoundError as ex:
And that's actually how this class of problems should be addressed:
instead of adding attributes to exceptions and exception guards to language -
just design your exception classes better.
We have multiple inheritance after all, the perfect method of classifying
objects/exceptions, why should we code information about the exception class
to some attribute?
If some library unifies all types of exceptions in one 'S3ResponseError'
exception - that's the problem of the library design.
More information about the Python-ideas