On Fri, Apr 8, 2011 at 11:22 AM, Mike Graham <mikegraham@gmail.com> wrote:

On Fri, Apr 8, 2011 at 1:52 PM, Guido van Rossum <guido@python.org> wrote:

...

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.

Gotcha. I would actually say this is somewhat special because urlopen can raise so many different errors; thatr's why I called it out as an example earlier. If all errors raisable by urlopen due to external circumstances would derive from some common base exception, people would catch that exception. I agree that the "except Exception as e if not isinstance(BadCodeError):" idiom is not great, and given that it is such a mouthful, people who are currently writing "except:" are unlikely to change their ways.

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

You seem to be missing the reason why we introduced BaseException here... Read PEP 352.

                 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.

But honestly that wasn't my intended use case. I was thinking more along the lines of trying to catch OSError with a specific errno value: except OSError as e if e.errno == errno.ENOTOBACCO: logging.info('Pipe has no tobacco')

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

I don't think we can define "negative" exception classes.

...

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.

But it's too late for that -- BadCodeError must derive from Exception, and most 3rd party code also defines exceptions deriving from Exception. -- --Guido van Rossum (python.org/~guido)

On Fri, Apr 8, 2011 at 2:32 PM, Guido van Rossum <guido@python.org> wrote:

On Fri, Apr 8, 2011 at 11:22 AM, Mike Graham <mikegraham@gmail.com> wrote:

...

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

You seem to be missing the reason why we introduced BaseException here... Read PEP 352.

I think I get what BaseException was conceived for, but it usually proves unsuitable for my usage. If I just do "except Exception" in this code (is that the idea?), it doesn't behave like I'd want: a) If my program exits due to a KeyboardInterrupt, it doesn't make it into my log, which I may want. b) If my program exits due to a loose GeneratorExit, it doesn't make it into my log, which I almost certainly want, and c) Plenty of Exception subclasses (like MemoryError and any sort of candidate for BadCodeError) are things that should be treated as uncatchable as often as the exceptions which don't subclass Exception. Perhaps I'm letting this cloud my vision of why you want BadCodeError.

...

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.

But honestly that wasn't my intended use case. I was thinking more along the lines of trying to catch OSError with a specific errno value:

except OSError as e if e.errno == errno.ENOTOBACCO: logging.info('Pipe has no tobacco')

I'm confused how that relates to BadeCodeError?

I don't think we can define "negative" exception classes.

class NotBadCodeError(Exception): __metaclass__ = abc.ABCMeta @classmethod def __subclasshook__(self, potential_subclass): if not issubclass(potential_subclass, BadCodeError): return True return False DON'T JUDGE ME!

But it's too late for that -- BadCodeError must derive from Exception, and most 3rd party code also defines exceptions deriving from Exception. Right.

Mike

On Fri, Apr 8, 2011 at 11:22 AM, Mike Graham <mikegraham@gmail.com> wrote:

On Fri, Apr 8, 2011 at 1:52 PM, Guido van Rossum <guido@python.org> wrote:

...

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.

Gotcha. I would actually say this is somewhat special because urlopen can raise so many different errors; thatr's why I called it out as an example earlier. If all errors raisable by urlopen due to external circumstances would derive from some common base exception, people would catch that exception. I agree that the "except Exception as e if not isinstance(BadCodeError):" idiom is not great, and given that it is such a mouthful, people who are currently writing "except:" are unlikely to change their ways.

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

You seem to be missing the reason why we introduced BaseException here... Read PEP 352.

                 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.

But honestly that wasn't my intended use case. I was thinking more along the lines of trying to catch OSError with a specific errno value: except OSError as e if e.errno == errno.ENOTOBACCO: logging.info('Pipe has no tobacco')

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

I don't think we can define "negative" exception classes.

...

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.

But it's too late for that -- BadCodeError must derive from Exception, and most 3rd party code also defines exceptions deriving from Exception. -- --Guido van Rossum (python.org/~guido)

On Fri, Apr 8, 2011 at 2:32 PM, Guido van Rossum <guido@python.org> wrote:

On Fri, Apr 8, 2011 at 11:22 AM, Mike Graham <mikegraham@gmail.com> wrote:

...

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

You seem to be missing the reason why we introduced BaseException here... Read PEP 352.

I think I get what BaseException was conceived for, but it usually proves unsuitable for my usage. If I just do "except Exception" in this code (is that the idea?), it doesn't behave like I'd want: a) If my program exits due to a KeyboardInterrupt, it doesn't make it into my log, which I may want. b) If my program exits due to a loose GeneratorExit, it doesn't make it into my log, which I almost certainly want, and c) Plenty of Exception subclasses (like MemoryError and any sort of candidate for BadCodeError) are things that should be treated as uncatchable as often as the exceptions which don't subclass Exception. Perhaps I'm letting this cloud my vision of why you want BadCodeError.

...

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.

But honestly that wasn't my intended use case. I was thinking more along the lines of trying to catch OSError with a specific errno value:

except OSError as e if e.errno == errno.ENOTOBACCO: logging.info('Pipe has no tobacco')

I'm confused how that relates to BadeCodeError?

I don't think we can define "negative" exception classes.

class NotBadCodeError(Exception): __metaclass__ = abc.ABCMeta @classmethod def __subclasshook__(self, potential_subclass): if not issubclass(potential_subclass, BadCodeError): return True return False DON'T JUDGE ME!

But it's too late for that -- BadCodeError must derive from Exception, and most 3rd party code also defines exceptions deriving from Exception. Right.

Mike