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.)