Python style: exceptions vs. sys.exit()

[Drake]

I have a general question of Python style, or perhaps just good
programming practice.

My group is developing a medium-sized library of general-purpose
Python functions, some of which do I/O. Therefore it is possible for
many of the library functions to raise IOError Exceptions. The
question is: should the library function be able to just dump to
sys.exit() with a message about the error (like "couldn't open this
file"), or should the exception propagate to the calling program which
handles the issue?

Thanks in advance for anyone who can either answer my question or
point me to where this question has already been answered.

[Grant Edwards]

On 2008-09-24, Steven D'Aprano <st****@REMOVE. THIS.cybersourc e.com.auwrote:

On Tue, 23 Sep 2008 13:25:26 -0700, Drake wrote:

>I have a general question of Python style, or perhaps just good
programming practice.

My group is developing a medium-sized library of general-purpose Python
functions, some of which do I/O. Therefore it is possible for many of
the library functions to raise IOError Exceptions. The question is:
should the library function be able to just dump to sys.exit() with a
message about the error (like "couldn't open this file"), or should the
exception propagate to the calling program which handles the issue?

Thanks in advance for anyone who can either answer my question or point
me to where this question has already been answered.

Presumably somebody has suggested that calling sys.exit() was a good
option. I'm curious to what possible reason they could give for such a
poor choice.

Same here. It's like an automotive engine controls designer
asking if a failed O2 sensor should turn on the check engine
light or blow up the car.

--
Grant Edwards grante Yow! Mr and Mrs PED, can I
at borrow 26.7% of the RAYON
visi.com TEXTILE production of the
INDONESIAN archipelago?

[Tim Rowe]

2008/9/24 Bruno Desthuilliers <br************ ********@websit eburo.invalid>:

Drake a écrit :

>many of the library functions to raise IOError Exceptions. The
question is: should the library function be able to just dump to
sys.exit() with a message about the error (like "couldn't open this
file"),

Arrghll ! NO, DONT !

Can I put in a vote *for* the questioner's library dumping to
sys.exit() on any abnormal condition? It would reduce employment
competition for the rest of us.

Why, yes, I am wearing my BOFH hat. How could you tell?

--
Tim Rowe

[Ross Ridge]

Steven D'Aprano <st****@REMOVE. THIS.cybersourc e.com.auwrote:

Presumably somebody has suggested that calling sys.exit() was a good
option. I'm curious to what possible reason they could give for such a
poor choice.

Grant Edwards <invalid@invali dwrote:

>Same here. It's like an automotive engine controls designer
asking if a failed O2 sensor should turn on the check engine
light or blow up the car.

No, it's more like asking if the failed sensor should turn on a strange
and mysterious light on the dashboard and then blow up the car if the
driver doesn't immediately stop and check the engine. The owners manual
would only vaguely hint at the fact that this could happen.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.u waterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

[Grant Edwards]

On 2008-09-24, Ross Ridge <rr****@csclub. uwaterloo.cawro te:

Steven D'Aprano <st****@REMOVE. THIS.cybersourc e.com.auwrote:

>Presumably somebody has suggested that calling sys.exit() was a good
option. I'm curious to what possible reason they could give for such a
poor choice.

Grant Edwards <invalid@invali dwrote:

>>Same here. It's like an automotive engine controls designer
asking if a failed O2 sensor should turn on the check engine
light or blow up the car.

No, it's more like asking if the failed sensor should turn on
a strange and mysterious light on the dashboard

You're right. I had forgotten that sys.exit() is actually
raising the system exit exception, and that the application
calling the library could handle that exception.

and then blow up the car if the driver doesn't immediately
stop and check the engine. The owners manual would only
vaguely hint at the fact that this could happen.

--
Grant Edwards grante Yow! Why is it that when
at you DIE, you can't take
visi.com your HOME ENTERTAINMENT
CENTER with you??

[Ross Ridge]

Steven D'Aprano <st****@REMOVE. THIS.cybersourc e.com.auwrote:

Presumably somebody has suggested that calling sys.exit() was a good
option. I'm curious to what possible reason they could give for such a
poor choice.

Grant Edwards <invalid@invali dwrote:

>Same here. It's like an automotive engine controls designer
asking if a failed O2 sensor should turn on the check engine
light or blow up the car.

Ross Ridge <rr****@csclub. uwaterloo.cawro te:

No, it's more like asking if the failed sensor should turn on
a strange and mysterious light on the dashboard

Grant Edwards <invalid@invali dwrote:

>You're right. I had forgotten that sys.exit() is actually
raising the system exit exception, and that the application
calling the library could handle that exception.

Well, my point was that exceptions in Python are a bit like a car's
check engine light. Few drivers know what this mysterious light means,
and aren't prepared to do anything about it when it goes on.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.u waterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

[Ross Ridge]

Grant Edwards <invalid@invali dwrote:

Same here. It's like an automotive engine controls designer
asking if a failed O2 sensor should turn on the check engine
light or blow up the car.

Ross Ridge <rr****@csclub. uwaterloo.cawro te:

No, it's more like asking if the failed sensor should turn on
a strange and mysterious light on the dashboard

Grant Edwards <invalid@invali dwrote:

You're right. I had forgotten that sys.exit() is actually
raising the system exit exception, and that the application
calling the library could handle that exception.

Ross Ridge a écrit :

Well, my point was that exceptions in Python are a bit like a car's
check engine light. Few drivers know what this mysterious light means,
and aren't prepared to do anything about it when it goes on.

Bruno Desthuilliers <bd************ *****@free.quel quepart.frwrote :

>You're kidding, aren't you ?

Of course not. Plenty of people were quick to say that the exception
should be passed through to the caller. No one said this behaviour
should be documented. There may be little practical difference bewteen
calling sys.exit() after printing an error and progating an exception
if no one using the library knows that it could generate that exception
in those circumstances.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.u waterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

[Craig Allen]

Why, yes, I am wearing my BOFH hat. How could you tell?

--
Tim Rowe

evil, but I think you may be a BSEFH, not a BOFH.

[Steven D'Aprano]

On Wed, 24 Sep 2008 10:54:40 -0500, Grant Edwards wrote:

You're right. I had forgotten that sys.exit() is actually raising the
system exit exception, and that the application calling the library
could handle that exception.

Could but shouldn't.

The exception hierarchy was re-designed in Python 2.5 specifically so
that SystemExit and KeyboardInterru pt no longer inherit from Exception.
That means this will do the right thing:

try:
process(record)
if changed:
update(record)
except Exception:
# don't write the record if any error occurs
pass
Neither SystemExit nor KeyboardInterru pt are errors, and they should not
be treated as errors. I quote from the Fine Manual:

[SystemExit] inherits from BaseException instead of StandardError or
Exception so that it is not accidentally caught by code that catches
Exception. This allows the exception to properly propagate up and cause
the interpreter to exit.

http://docs.python.org/lib/module-exceptions.html

SystemExit is not an error. KeyboardInterru pt is not an error. Libraries
should not use SystemExit to signal an error any more than they should
use MemoryError to signal a missing attribute.

Whether or not an application exits is up to the application to decide,
not the library it wraps. Libraries should report errors by raising an
Exception (note the capital E), and the application should decide whether
or not it is recoverable, and if not, exit (perhaps by simply not
catching the exception).

--
Steven

[Steven D'Aprano]

On Wed, 24 Sep 2008 17:11:28 -0400, Ross Ridge wrote:

Plenty of people were quick to say that the exception should be passed
through to the caller. No one said this behaviour should be documented.
There may be little practical difference bewteen calling sys.exit()
after printing an error and progating an exception if no one using the
library knows that it could generate that exception in those
circumstances.

That's true, I didn't explicitly say that the library should be
documented. Nor did I say that it shouldn't be riddled with bugs. There's
little practical difference between a buggy library and one that raises
unexpected (i.e. undocumented) exceptions either.

--
Steven

[Bruno Desthuilliers]

Steven D'Aprano a écrit :

On Wed, 24 Sep 2008 17:11:28 -0400, Ross Ridge wrote:

>Plenty of people were quick to say that the exception should be passed
through to the caller. No one said this behaviour should be documented.
There may be little practical difference bewteen calling sys.exit()
after printing an error and progating an exception if no one using the
library knows that it could generate that exception in those
circumstance s.

That's true, I didn't explicitly say that the library should be
documented. Nor did I say that it shouldn't be riddled with bugs. There's
little practical difference between a buggy library and one that raises
unexpected (i.e. undocumented) exceptions either.

Also note that there are quite a couples cases where the library authors
themselves cannot predict which exception types may be raised - as soon
as the library functions expect callback functions, file-like or
dict-like or whatever-like objects etc, it's the caller's responsability
to handle the exceptions that may be raised by what *he* passes to the
library...