[Python-ideas] Consistent programming error handling idiom

[Chris Angelico]

On Sat, Apr 9, 2016 at 5:01 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sat, Apr 09, 2016 at 04:28:47AM +1000, Chris Angelico wrote:
>
>> ANY uncaught exception is a bug.
>
> What, even SystemExit and KeyboardInterrupt?

In terms of a boundary location? Yes, probably. If you're writing a
web server that allows web applications to be plugged into it, you
probably want to let the console halt processing of one request, then
go back and handle another. Although it is contextual; you might
choose the other way, in which case it's "any uncaught subclass of
Exception is a bug", or "anything other than KeyboardInterrupt is a
bug", or some other definition. I'm on the fence about SystemExit; in
any context where there's this kind of boundary, sys.exit() simply
wouldn't be used. So it could viably be called a bug, or it could
validly be used to terminate the entire server.

>> Any caught exception is not a bug.
>
> Even:
>
> try:
>     ...
> except:
>     # Look, bug free programming!
>     pass

As far as the boundary location's concerned, yes. The inner code can
be as ridiculous as it likes, but the boundary will never do the "log
and resume" if all exceptions are caught. (It won't even get an
opportunity to.)

> I am sure that any attempt to make universal rules about what is or
> isn't a bug will be doomed to failure. Remember that people can write
> code like this:
>
> # Writing a BASIC interpreter in Python.
> if not isinstance(command[0], int):
>     raise SyntaxError('expected line number')
>
> So, no, SyntaxError does not necessarily mean a bug in your code. *ALL*
> exceptions have to be understood in context, you can't just make a
> sweeping generalisation that exception A is always a bug, exception B is
> always recoverable. It depends on the context.

If one escapes to a boundary, then yes it does. That's the context
we're talking about here.

ChrisA