Wrapping exceptions versus propagating them untouched

January 14, 2007

I have somewhat recently written a program that makes heavy use of Python's xmlrpclib module. While the xmlrpclib module is very nice, the whole experience has given me some strong views on how it does exception handling.

The basic problem with xmlrpclib's error handling is that it doesn't capture exceptions from stuff that it calls, so they leak out to you. Fortunately I don't think xmlrpclib calls anything that can raise errors except the socket module, but I'm not sure (so my program may someday detonate with an uncaught error).

I suspect that there is a big debate over whether you should wrap exceptions from stuff you call or just pass them through, but having gone through the experience of dealing with xmlrpclib I have to come down solidly on the side of 'wrap exceptions'; it is simply much easier to deal with. It also means that I am less exposed to the internal details of how your module is implemented. As it is, I will have to modify my program if a future version of xmlrpclib starts calling something else that can also raise exceptions.

So one way to put it is that by not capturing exceptions from stuff your module calls, you make what your module calls part of your module's interface, because users of your module have to be aware of it in order to use your module safely. (And if some of those modules behave the same way, what they call is implicitly added to your module's interface and so on.)

History has shown us that large, vulnerable to change interfaces are pretty much a bad idea; you want small stable interfaces instead. Yes, wrapping up other people's exceptions in your own exceptions inevitably loses some information, but it's almost always going to be worth it.

(Maybe this is conventional wisdom, but since the xmlrpclib module doesn't wrap exceptions I suspect that it is not as widespread as I would like.)

Written on 14 January 2007.
« An alarming reflex in my use of find
Configuring VLANs on Fedora Core »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jan 14 22:56:32 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.