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

[Cameron Simpson]

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")

Who here thinks that is useful to a _program_ for inspecting issues?
It's the equivalent of the useless bug report "foo is broken!"

When we're raising an exception for something that should not occur,
indicating a programming bug, the above is fine; for a system failure
requiring a programmed and appropriate response, the above is pretty
vague.

OSError and IOError fall pretty clearly into the latter category, and so
does S3ResponseError and so (should) a bunch of other exceptions raised
by libraries.

So in a better quality exception environment, the "if" qualifier would
have many more use cases that Antoine encounted while writing his PEP?

So I'm a big +1 for the:

  except foo as bar if wibble:

syntax. We do it for list comprehensions, we (kicking and screaming) do
it for the tertiary choice operator (eschewing C's ?: notation) and I
think we should do it here.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au>

Outside of a dog, a book is a man's best friend.  Inside of a dog, it's too
dark to read. - Groucho Marx