quinn at challenge
Mar 8, 1999, 5:21 PM
Post #2 of 4
(382 views)
Permalink
|
|
Re: Changes to error handling output - where?
[In reply to]
|
|
> I'm interested in making a change to the way errors are reported, but I'm
> having a hard time nailing down where the changes need to be made.
>
> (All statements reflect what I see in 1.9.0. I'm moving toward 1.10.2, but
> am not quite there.)
>
> I'd like BOBO_DEBUG_MODE/Z_DEBUG_MODE to accept three values: 0 & 1 would
> have the same effect as they currently do. For any other value, I'd like
> the system to treat the value as an email address & subject and mail the
> traceback to the given address using the given subject. For example, a
> value something like "skip [at] mojam:Bobo Traceback" would send a message to
> skip [at] mojam with a subject of "Bobo Traceback" containing the traceback.
>
> I've been able to figure out that BOBO_DEBUG_MODE and Z_DEBUG_MODE are
> fiddled in ZPublisher.Publish.get_module_info, but I can't see where
> bogosities in executed methods are caught and handled. Any pointers would
> be greatly appreciated.
This is the same sort of thing I was wrestling with when I made my exception
handler comments, but I didn't receive any sort of feedback to that. My idea
was that you could have a BoboException or something which you subclass your
own exceptions off of. Then you put your error handling, webmaster-mailing,
web-page throwing stuff in your exception's __str__ method. AFAIK, the only
change required is adding an isinstance() line in Response.py. Of course,
this code could also snag sys.exc_info() and thus provide custom traceback
formatting and we could lose all the hard coded stuff in Response.py. Perhaps
BoboException could have a dtml attribute which is called if it's present for
the error page (since dtml works nicer when ZPublisher calls it instead of
python), and a handler attribute which is called if present (although its
results should be available to the dtml), as it would be a little more
intuitive to override BoboException.handler instead of BoboException.__str__.
Anyway, I think this would be a more general solution than adding more baggage
to Z_DEBUG_MODE (and what if you only want some errors mailed?), and could
provide a generalized and intuitive way of handling all errors gracefully
without doing lots of ad res error checking (that's what exceptions are for,
no?). And we could eliminate Z_DEBUG_MODE and __bobo_hide_tracebacks__ and
all those magic globals and have the same functionality by setting
BoboException attributes... all your exceptions inherit it and do what you
want, unless they explicitly override it.
Once again, what do people think? Should I submit to Collector? Forget about
it, it's already solved a different way? Mutilate ZPublisher and send
patches?
|
