Re: exception handling in complex Python programs

On Aug 19, 10:19 am, eliben <eli...@xxxxxxxxx> wrote:

P.S. There's a common case where a method is passed a filename, to do
something with a file (say, read data). Should the method catch the
errors possibly thrown by open(), or leave it to the caller ?

You want to look up Easier to Ask Forgivness than Permission (EAFP)
which is touted as the "canonical" error-handling paradigm for Python.
This would give rise to the following function:

def do_something(filename):
try:
f = open(filename)
except IOError:
return err("File %s not found" % filename)
...

where err is a function that generates an error object that your
application understands. I personally think this is sloppy because you
have to couple the exception type with the function --- between file()
and open() in Python 2 and 3, a NameError is thrown with open() in
Python 3 and an IOError is thrown in the other three cases <bashes
head against keyboard>. The alternative is

def do_something(filename):
if not os.access(filename,os.R_OK):
return err(...)
f = open(filename)
...

or, (and this last one I actually used for a web application)

def do_something(filename):
if not os.access(filename,os.R_OK):
raise MyApplicationsExceptionType("File not found...")
f = open(filename)
...

The last one has the advantage that you can write a request handler
like this

def handle_http_request(...):
func = specific_handler_func(...)
try:
response = func(...)
return response
except MyApplicationsExceptionType as exc: #3.0 syntax
return error_response(exc,...)

Exceptions you don't expect (i.e. bugs) will get handled by the web
app framework, but you get to handle your own exceptions. Raising your
own exception type can also be employed with the EAFP approach like
this:

def do_something(filename):
try:
f = open(filename)
except IOError:
raise MyApplicationsExceptionType("File %s not found" %
filename)
...

If you are writing a library (for instance using a file for persistent
storage), then the answer to your question is "don't catch the
exception." Clients will expect the usual exception to be thrown when
a bad file name is passed.

David
.

Relevant Pages

  • Re: exception handling in complex Python programs
    ... errors possibly thrown by open, or leave it to the caller? ... def do_something: ... This "error object" is useless, *returning* it ruins the whole point of structured exception handling and take us back to infamous C error code checking, and - icing on the cake - the error message is very possibly wrong and misleading (IOError dont necessarily mean 'file not found'). ... This kind of exception "handling" manages to be worse than no exception handling at all. ...
    (comp.lang.python)
  • Re: Fwd: Should I use "if" or "try" (as a matter of speed)?
    ... good practice is "Always catch any possible exception that might be thrown by a library I'm using on the same line as it is thrown and deal with it immediately." ... To me, this code seems very logical and straightfoward, yet it doesn't catch the exception on the very next line following its generation. ... except IOError: #File doesn't exist ...
    (comp.lang.python)
  • Re: How do I catch ExpatError exception?
    ... def r: ... import sys ... How do I get the helpful text that is thrown with the exception? ... How do I get the the text after IOError:? ...
    (comp.lang.python)
  • Re: itertools.flatten()? and copying generators/iterators.
    ... def flatten_po: ... 100 loops, best of 3: ... I fully expected pro_am to be slower, ... BUT only at the cost of an exception. ...
    (comp.lang.python)
  • Re: The ducks backside
    ... then a runtime exception will be thrown. ... def initialize(_a, _b, _c) ... # parameter of of the wrong static type. ... def static_type_check(klass) ...
    (comp.lang.ruby)