[Python-ideas] syntax to continue into the next subsequent except block

[Yury Selivanov]

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
> uninspectable:
> 
>  raise ValueError("arbitrary prose here")

So you want to write code like:

   except ValueError as ex if 'foo is wrong' in ex.args[0]:

?

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
of writing

   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.

Big -1.

-
Yury