error handling in Python

[beliavsky]

Suppose I have a function

def read_data(xfile):
# code here to read dates and prices
return dates,prices

that if successful returns two Numeric arrays, of dates and prices. I
am unsure what to return if read_data is unsucessful. Since a
successful function call returns a list of length two, I could return
a list of length one if there is a problem, so that [-1] is returned
if the file does not exist, [-2] if the dates are invalid, etc. After
calling the function, I could check the len of the result to detect
problems. This seems workable but ad-hoc.

I do NOT want to use the try/except idiom to stop the program if there
is a problem reading data.

In Fortran I would write a subroutine with calling sequence

call read_data(xfile,dates,prices,ierr)

where ierr would be checked upon return for nonzero values.

 

[Diez B. Roggisch]

that if successful returns two Numeric arrays, of dates and prices. I
am unsure what to return if read_data is unsucessful. Since a
successful function call returns a list of length two, I could return
a list of length one if there is a problem, so that [-1] is returned
if the file does not exist, [-2] if the dates are invalid, etc. After
calling the function, I could check the len of the result to detect
problems. This seems workable but ad-hoc.

are you aware of the multiple assignment capabilities of python? You can do
it like this:

def foo():
a = compute_me()
b = me_too()
return a,b

s, t = foo()

so basically you can simply return always three values: your results, and an
error value. The value then is checked.

I do NOT want to use the try/except idiom to stop the program if there
is a problem reading data.

Why not? exceptions are definetely the best way (at least in python) to deal
with error conditions. You should utilize them. And they don't stop the
program - only if you want them to. The big advatage is that the programmer
becomes aware of an error condition, while with your approach she can
easily forget to check for the error.

 

[John Roth]

Suppose I have a function

def read_data(xfile):
# code here to read dates and prices
return dates,prices

that if successful returns two Numeric arrays, of dates and prices.

It looks like you're still thinking in Fortran. It's probably going to
be easier all around to return one list of two element tuples.

I am unsure what to return if read_data is unsucessful. Since a
successful function call returns a list of length two, I could return
a list of length one if there is a problem, so that [-1] is returned
if the file does not exist, [-2] if the dates are invalid, etc. After
calling the function, I could check the len of the result to detect
problems. This seems workable but ad-hoc.


I do NOT want to use the try/except idiom to stop the program if there
is a problem reading data.

In Fortran I would write a subroutine with calling sequence

call read_data(xfile,dates,prices,ierr)

where ierr would be checked upon return for nonzero values.

The basic question is: what do you want to do with an error?
That conditions how you want to handle it. Do you want to print
an error message and quit? Print an error message and continue
with the next batch? Fake up a return so the rest of the program
continues as if nothing was wrong?

John Roth

 

[Paul McGuire]

I do NOT want to use the try/except idiom to stop the program if there
is a problem reading data.

Unlike FORTRAN, exceptions in Python do not necessarily stop the program -
they only do so if not handled.

In your case, you know just where read_data() is called from, so you can
catch a thrown exception and do the appropriate
cleanup/retry/shutdown/ignore-and-continue, all without having to figure out
what "special" value to put in the return code to indicate a failure. You
also don't have to clutter up your read_data() argument list with error
codes, error descriptions, I/O status, etc. - put that stuff in attributes
of the thrown exception, and leave your read_data() arguments to deal with
the read_ing of data.

Don't try to hack around try-except's mechanisms for invoking exception
code, by using magic return codes ("if zero, that means success; if greater
than zero, that's a warning; less than zero is an error") and exception-only
method arguments. Cleaning this stuff out of your method signature is a
*good* thing, and let's you focus on the functional task, while try-except
offers a clear, robust, supported mechanism for signalling, um, let's not
call them "failures", how about "alternative return paths"?

-- Paul