Refined Error Handling
Gunfighter
The additions of an identity/security module and the CatWalk model
browser are obviously big steps towards a viable web platform. There
had actually been some changes and updates (nothing major) to the base
systems as well, so I decided to run through the 20 minute Wiki
tutorial again (coding it, not just watching it).
I can type rather quickly, but nobody's perfect. Thanks to my typos, I
generated some rather interesting errors that made TurboGears
misbehave. I mean... like... really misbehave. Sure I had my share of
misspelled variable names. I kept hitting refresh only to find that I
didn't have an object called "pate". A quick glance in my controller
allowed me to change it to "page" and get back on track. Luckily, I'm
familiar enough with Python to decode all of the gibberish it spits out
and get straight to the error for logic problems that display in the
page. However, I feel for the unwashed who see what the errors produce
and have no idea where to even start looking. I think this can probably
be handled better (and possibly even provide a little automated
hand-holding).
Before I continue, there is one particular situation I need to directly
address. One particular typo was a complete showstopper. By "complete
showstopper" I mean it stopped the entire TurboGears daemon dead in its
tracks. Trying to load http://localhost:8080/ threw up a "Connection
refused" message. Naturally, I looked in the console where I was
running TG and found the error. As it turns out, TG had attempted to
reload my model.py and barfed on a typo. I had tried to call the comple
(typo for compile) method on my wikiwords re object. Whoops! Again,
this was easily fixed, but I pity the remote developer who may not have
access to such information.
So how can these be improved? Some obvious suggestions come to mind.
One particular thought is to have the error handling page load the
Simple Description, TraceBack, and any other pertinent information in
JSON format. Perhaps display the true error in a simple format (e.g.
"No such method comple in model.py on line 123") and have a "Click here
for traceback" link that would display the full traceback information.
As far as the model.py error completely stopping TG, I think that would
(obviously) be relegated to error handling code elsewhere in the MVC
chain.
Disclaimer: This message was cut & paste from the original which can be
found here:
http://gunfighter.blogspot.com/2005/11/paint-me-pretty-uhm-error.html
Just my $0.02.
-- Gun
Kevin Dangoor
On 11/1/05, Gunfighter <gunfi...@gmail.com> wrote:
> So how can these be improved? Some obvious suggestions come to mind.
> One particular thought is to have the error handling page load the
> Simple Description, TraceBack, and any other pertinent information in
> JSON format. Perhaps display the true error in a simple format (e.g.
> "No such method comple in model.py on line 123") and have a "Click here
> for traceback" link that would display the full traceback information.
form to quickstart, that would give people a leg up in making a
customized version for their own projects. I added a ticket for this:
http://trac.turbogears.org/turbogears/ticket/86
> As far as the model.py error completely stopping TG, I think that would
> (obviously) be relegated to error handling code elsewhere in the MVC
> chain.
their development on machines separate from their production servers.
(Right?)
That said, the start script *could* do something like wrap the
majority of the startup procedure in a try/except and then, if an
exception is raised, fire up cherrypy with a root that shows nothing
other than the error page. I just don't think that's particularly
necessary. If your model.py is broken, you're site is down anyway.
Kevin