[Python-ideas] syntax to continue into the next subsequent except block
cs at zip.com.au
Sun Sep 16 04:20:28 CEST 2012
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")
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
OSError and IOError fall pretty clearly into the latter category, and so
does S3ResponseError and so (should) a bunch of other exceptions raised
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.
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
More information about the Python-ideas