Exception report library

[Ian Bicking]

Robert Brewer wrote:
>>I've been using one of several systems to catch unexpected exceptions 
>>and log them (e.g., write to a file, display on web page, email me, 
>>etc).  But many are built into a particular system, or have an 
>>interesting but incomplete set of features.  E.g., many web 
>>frameworks have exception reporters (and the stdlib includes cgitb),
>>but I want to handle non-web exceptions in the same way as exceptions
>>from web requests, and that's not generally easy.
> 
> ...
> 
>>I feel like there must be something out there, since every Python 
>>programmer has to deal with this sort of thing to some degree...?
> 
> 
> I feel that way, too, but haven't found it. I broke my webapp framework
> out of my ORM late last year, and quickly realized how small the core
> framework really is (22k, versus 250k for the web bits). Features like
> the logging handler could be provided as separate modules, rather than
> built into the Application object, and I've been meaning to get around
> to that. If we could put our many heads together, I think this would be
> doable for the stdlib.

I'm not optimistic about a good exception handler in the standard 
library; development slows down a lot at that point, and it's not a 
reasonable candidate until it is designed and used (in part because of 
that slowdown -- if it's not mature, it is a diservice to the project to 
calcify the interface with such strong backward compatibility 
requirements).  But anyway, hopefully multiple 
people/frameworks/projects could use such a library, done well, as a start.

> Here are the pieces of the framework, by the way, which might also
> benefit from some standardization (I was thinking about them all at
> once):
> 
>    1. Thread-safe application state
>    2. Logging (+ exception handling)
>    3. Configuration data (reading from various sources)
>    4. Registry of Workers for getting things done on a schedule,
> possibly recurring
>    5. Registry of startup/shutdown functions
>    6. Registry of active user interfaces
> 
> I think the first three are all good candidates for a standard. If we
> had a standard, thread-safe Application object, the rest could be
> registerable plugins for that. You'd basically register callbacks for
> app.startup and .shutdown methods to iterate over.

Hmm... I'm confused by these bits.  Are you talking about libraries for 
other parts of a web framework, besides exception handling?  If so, you 
might want to look into WSGI and then discuss these things on the 
web-sig list (WSGI as a starting point; it doesn't specifically relate 
to many of these ideas, but provides a context in which to develop 
them).  Some of these have been discussed there, like logging, 
configuration, and perhaps aspects of the registration you are thinking 
about.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org