[e-lang] Remaining semantic issues

zooko at zooko.com zooko at zooko.com
Wed Jun 1 13:39:28 EDT 2005

 MarkM wrote:
> I think this is a terribly important question. My general experience is that 
> API designers go to a lot of trouble to distinguish different error cases, so 
> callers could dispatch on them, but that callers invariably do something like
>      if (read(...) < 0) {
>          perror(...)
>          // react to a failure to read
>      }
> Could you show us some code that dispatches on these errors to do something 
> useful? A few illustrative examples of successful error handling, which depend 
> on what error happened, may teach us all a lot.

The standard guidelines in all the Python projects I've worked on is that you
should never catch all possible exceptions (which in Python is accomplished by
catching the superclass of exceptions), but instead catch only the cases which
you believe would be correctly handled by your exception handler.

In practice, a general catch is still occasionally used, but usually because of
some special circumstance.  For example, I grepped in my pyutil library and
found 56 catch statements, 15 of which caught general exception, but those
were almost all because they were in "language implementation"-like code and 
many of them subsequently re-threw the specific exception.

I once had a patch rejected from the Twisted Python project because my patch 
contained an unjustified catch-all-exceptions clause.

I hope this is relevant to what you were asking.

You could find detailed examples by grepping for "except" in 




More information about the e-lang mailing list