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.

[Larry Bates]

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.

IMHO libraries should always just let the exception propagate up to the caller.
That allows the caller the option of taking the appropriate action.

-Larry

[Grant Edwards]

On 2008-09-23, Drake <cj*****@gmail. comwrote:

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"),

No. A library module should never call sys.exit().

or should the exception propagate to the calling program which
handles the issue?

Yes. Let the application handle the error if it wants to. If
it's not handled, it'll end up causing the program to exit.

--
Grant Edwards grante Yow! It's a hole all the
at way to downtown Burbank!
visi.com

[Craig Allen]

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?

my view is that the exceptions are there precisely to tell the calling
program about the error and give the programmer a chance to do
something smart about it. A library, properly, doesn't even know the
context in which it is running, and sys.exit() is pretty heavy handed
for a library to call and shows assumptions beyond what a library
should assume about its running environment.

imho

[Terry Reedy]

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"),

No

or should the exception propagate to the calling program which
handles the issue?

Yes -- with an informative error message.

If the caller ignores the exception, the program will exit with a full
stack trace anyway.

[Christian Heimes]

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?

Side note:

sys.exit() is just another way to write raise SystemExit. The function
is defined as:

static PyObject *
sys_exit(PyObje ct *self, PyObject *args)
{
PyObject *exit_code = 0;
if (!PyArg_UnpackT uple(args, "exit", 0, 1, &exit_code))
return NULL;
/* Raise SystemExit so callers may catch it or clean up. */
PyErr_SetObject (PyExc_SystemEx it, exit_code);
return NULL;
}

Christian

[Steven D'Aprano]

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.

Hint: if a library function can't open a file, the application should be
given the opportunity to open a different file. Or do something
completely different instead. Whatever. That's not up to the library to
decide, not even if the library is in such a broken state that it can't
continue. Why not? Because the application might deal with that by
unloading the library and continuing regardless.

--
Steven

[Asun Friere]

On Sep 24, 8:10 am, Christian Heimes <li...@cheimes. dewrote:

Side note:

sys.exit() is just another way to write raise SystemExit. The function
is defined as:

As can be seen if you were ever silly enough to call sys.exit() in
IDLE. ;)

[Bruno Desthuilliers]

Drake a écrit :

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"),

Arrghll ! NO, DONT !

or should the exception propagate to the calling program which
handles the issue?

Yes, by all means and for God's sake.

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

There have been numerous threads about this here.

[Carl Banks]

On Sep 23, 4:25*pm, Drake <cjdr...@gmail. comwrote:

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"),

I'm kind of curious what your library is for. Is it something where
exiting the app be the only appropriate action for an IO error?

Even if it is, I will echo other people's advice: a library should
never call exit, at least not by default. For your imagined use it
might make sense to exit upon any failure, but other people using the
library might not want to do that.

For that matter, a library should never print error or status
messages. Messages should either be sent to the caller somehow, or
handled using the logging facility.
Carl Banks