When dealing seriously with error handling, an important technique is to be able to manipulate exceptions in ways other than simply throwing and catching them. One of these is to re-throw exceptions.

The simplest way to do this is if you need to perform a little work after the catch, but then immediately re-throw. This can be done with a simple raise statement:

try:
    do_something_dangerous()
except:
    do_something_to_apologize()
    raise

Here the raise statement means, "throw the exception last caught". This is a simple case, and I probably didn't need to remind you of it. But a more sophisticated technique is to catch an exception in one place, and raise it again in another.

For example, you may have a worker thread pre-fetching data from slow storage, and then on the main thread, the consumer of the data either gets the data or sees the exception that prevented him from getting the data.

Here's the simple implementation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
class DelayedResult:
    def __init__(self):
        self.e = None
        self.result = None
        
    def do_work(self):
        try:
            self.result = self.do_something_dangerous()
        except Exception, e:
            self.e = e

    def do_something_dangerous(self):
        raise Exception("Boo!")

    def get_result(self):
        if self.e:
            raise self.e
        return self.result
    
dr = DelayedResult()
dr.do_work()
dr.get_result()

We store an exception in the object, and when retrieving the result, if there's an exception, we raise it. It works:

$ python delayed.py
Traceback (most recent call last):
  File "C:\lab\delayed.py", line 22, in ?
    dr.get_result()
  File "C:\lab\delayed.py", line 17, in get_result
    raise self.e
Exception: Boo!

The only problem is, the traceback for the exception shows the problem starting in get_result. When debugging problems, it's enormously helpful to know their real origin.

To solve that problem, we'll store more than the exception, we'll also store the traceback at the time of the original problem, and in get_results, we'll use the full three-argument form of the raise statement to use the original traceback:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class DelayedResult:
    def __init__(self):
        self.exc_info = None
        self.result = None
        
    def do_work(self):
        try:
            self.result = self.do_something_dangerous()
        except Exception, e:
            import sys
            self.exc_info = sys.exc_info()
    
    def do_something_dangerous(self):
        raise Exception("Boo!")

    def get_result(self):
        if self.exc_info:
            raise self.exc_info[1], None, self.exc_info[2]
        return self.result
    
dr = DelayedResult()
dr.do_work()
dr.get_result()

Now when we run it, the traceback points to do_something_dangerous, called from do_work, as the real culprit:

$ python delayed.py
Traceback (most recent call last):
  File "C:\lab\delayed.py", line 23, in ?
    dr.get_result()
  File "C:\lab\delayed.py", line 8, in do_work
    self.result = self.do_something_dangerous()
  File "C:\lab\delayed.py", line 14, in do_something_dangerous
    raise Exception("Boo!")
Exception: Boo!

The three-argument raise statement is a little odd, owing to its heritage from the old days of Python when exceptions could be things other than instances of subclasses of Exception. This accounts for the odd tuple-dance we do on the saved exc_info.

It's easy to write code that does the right thing when everything is going well. It's much harder to write code that does a good job when things go wrong. Properly manipulating exceptions helps.

tagged: , » 10 reactions

Comments

[gravatar]
Neil Barnwell 2:41 AM on 14 Nov 2007

The amount of times I've seen this in C# code is baffling:

try
{
DoSomethingDangerous();
}
catch (Exception ex)
{
throw ex;
}

So if DoSomethingDangerous() throws an exception (worse, if one of its sub-methods!) that isn't caught, then I have almost no idea where the exception came from.

[gravatar]
Ned Batchelder 6:38 AM on 14 Nov 2007

There's two explanations:

1) There used to be something else in the catch clause, like a print statement, or they wanted a place to put a breakpoint.

2) They just aren't used to the idea of exceptions flowing through their code, and want to somehow control it. Of course, they aren't adding anything here but a stop-off to throw away valuable information.

Either way, it's bad.

[gravatar]
Shawn Wheatley 1:40 PM on 14 Nov 2007

Neil,

You're right, the proper C# way should be:

try
{
ThrowSomeExceptionHere();
}
catch(Exception ex)
{
DoSomeLoggingAndNotification();
throw;
}

That will properly re-throw the exception and keep the stack trace intact. And of course, if you're not logging or doing something with the exception, why is there a catch block in the first place?

[gravatar]
john saponara 8:37 AM on 15 Nov 2007

i often catch an exception because in order to add info about the context to the exception and reraise it, and i found this to be helpful: http://blog.ianbicking.org/2007/09/12/re-raising-exceptions/

[gravatar]
Rafal Dowgird 9:05 AM on 15 Nov 2007

Here is the Java code for re-raising exceptions without losing any information:

try{
doSomethingDangerous();
}
catch(OneExceptionType e){
throw new AnotherExceptionType(e); // just pass the original exception to the constructor

Yup, that's it. As a bonus, you get both the original stack trace and the stack trace from re-raising. Compared to this, the 'proper' Python way is an ugly hack.

[gravatar]
Ian Bicking 4:45 PM on 15 Nov 2007

I think in the future the tb object (that holds the stack trace) will be attached to the exception directly, so re-raising exceptions will become easier. Maybe in Python 2.6?

[gravatar]
Bulkan Evcimen 7:03 AM on 16 Nov 2007

Great article, but i can see new Python programmers falling to the trap of catching an exception but instead of re-raising it they raise another, which is bad for debugging.

[gravatar]
Mikle 9:12 AM on 13 Dec 2007

I stumbled upon a great way to rethrow exception with a little more info (python of course):

try:
do_something_dangerous()
except Exception, e:
e.args = "Some smart and helpful message. The original message:\n%s" % e.args
raise

It adds some info without changing the traceback, so it's both a bit more helpful and it doesn't change the location from which it was thrown to the except location. Oh and it keeps the type of the exception, and doesn't convert it to Exception.

[gravatar]
nairbv 10:05 PM on 29 Apr 2008

Rafal Dowgird:

I duno, I seem to remember finding problems with this in Java. I'm not sure why... I at least remember finding code like "throw new SomeException(e.getMessage())", which absolutely drove me nuts.

hmm....

java programmers should still at least think about this kind of issue. I'm writing a little test program and can't seem to get it wrong, but I know I've seen it badly messed up, and had to fix a lot of code to be able to get real stack traces.

[gravatar]
Alberto Gaona 12:49 PM on 16 Jan 2009

Old principle: if you don't know how to handle an exception, don't catch it

Add a comment:

name
email
Ignore this:
not displayed and no spam.
Leave this empty:
www
not searched.
 
Name and either email or www are required.
Don't put anything here:
Leave this empty:
URLs auto-link and some tags are allowed: <a><b><i><p><br><pre>.