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

[Cameron Simpson]

On 16Sep2012 13:16, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
| 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:
| > | 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]:

No! Not at all. I was moaning about the lack of inspectability
of most of the exceptions, and ValueError is top of the list.
Of course, it has to be since we raise it for almost any sanity check
failure; there's not nice enumeration of the (unbounded) possible ways
a value may be unsuitable.

| 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.  

I disagree here. Fairly strongly, actually.

FOr the record I am much cooler on the except...if notion than I was
yesterday, +0 or maybe +0.5.

BUT...

OSErrno and IOError are generally built on low level OS APIs, and
returning errno is a highly correct thing to do. It passes our, _with_ the
exception (so it doesn't get maked by another library call, as the global
POSIX error is subject to), the actual OS-level failure that was reported.

Likewise with the S3 exceptions and probably any other well designed
exception response to a library call with an informative failure code.

| 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.

No, not necessarily. Having a ridiculous suite of a billion trite
subclasses to enumerate the return codes from a lower level (or more
"inner") library is just nuts.

The PEP class tree is handy to _group_ an assortment of failure
modes into small groups of the same flavour. But an exact one-to-one
between exception subclasses and errno values? Ghastly. It _doubles_
the cognitive burden on the dev and the code reader, because the
correspondence between the OS-level errno and the subclass names needs to
kept in mind if the program cares about the OS level failure mode. Which
it does if it is bothering to make a fine grained decision at all.

It is all very well to offer an, um, rich suite of subclasses representing
various library failure modes. But to toss the _actual_ library failure
indicator value in favour of a arbitrary and possibly incomplete class
name list? Bad, really bad. The exception _should_ carry with it the
underlying library failure code if the library has such a thing.

| Big -1.

I'm not +1 any more, but still +.
-- 
Cameron Simpson <cs at zip.com.au>

Judging by my employee ID# my employer thinks I am a small filing cabinet,
so I dont think they give a care about my opinions.
        - Michael Jones <michaelj at nafohq.hp.com>