Home Original page

[Python-ideas] Bad code exceptions (was PEP-3151 pattern-matching)

Mike Graham mikegraham at gmail.com
Fri Apr 8 20:22:01 CEST 2011 
On Fri, Apr 8, 2011 at 1:52 PM, Guido van Rossum <guido at python.org> wrote:
> I'm sorry, but I'm not quite following what you are saying here,
> perhaps due to the double negatives you seem to be using. (Or perhaps
> because my brain is not working 100% this morning. :-)

I'm pretty sure it's me!

> Could you elaborate, perhaps with a few examples of good practice, bad
> practice, how each would be written with and without the hypothetical
> "BadCodeError" exception, and which forms you'd consider good and bad
> style?

I imagine common usage would be

try:
    website = open_and_parse(url)
except Exception as e if not isinstance(e, BadCodeError):
    print("Error downloading %s." % url)

because I currently see tons of

try:
    website = open_and_parse(url)
except:
    print("Error downloading %s." % url)

The right thing to do would likely be to figure out which errors mean
you couldn't download the website and catch those. Here you might
accidentally squash exceptions raised in parsing and issue the wrong
error message.


A more appropriate usage might be

def my_event_loop(self):
    while True:
        try:
            self.advance()
        except BaseException as e:
             self.logger.exception()
             if isinstance(e, (NameError, AttributeError,
                               KeyboardInterrupt, SystemExit,
                               MemoryError)):
                  raise

Catchall exceptions (even of a slightly more limited nature) should be
a rarity and typically is caused by bugs. Since this is something that
should seldom be done and since there are borderline cases, I don't
think that a language-level change helps.

This list sort of suggests to me that I'm thinking more of
DoNotCatchThisError, which includes BadCodeError and
SomeExternalThingICannotHelpError.

> I could also see how combining this with the 'if' subclause might
> actually be beneficial:
>
> try:
>  <something highly experimental>
> except Exception as e if not isinstance(e, BadCodeError):
>  <apparently there was some bad data>

I imagine this would be by far the most common use of BadCodeError,
which suggests to me that if we had something like this, it would be
important to have (a better-named GoodCodeError) or CatchableError.

> Of course in reality bad data will often lead to a BadCodeError, the
> most common example being trying to call a method on a value that is
> unexpectedly None. Maybe getattr(None, anything) should raise some
> other exception? (Clearly just thinking aloud here. :-)
>
> --
> --Guido van Rossum (python.org/~guido)

Mike
More information about the Python-ideas mailing list