I've also found that Webware/WebUtils/cgitb.py hadles non object
errors (ie: raising a string as the error) improperly causing the
'fancy traceback' to fail to display the actual traceback. Here is a
change that works for me, but i think it would be better to do enough
error checking to never rely on the except block here as falling into
that block makes *that* exception and not the original exception be
printed in the fancy traceback.
< try:
< etype = etype.__name__
< except AttributeError:
< pass
---
> if etype and type(etype) != type(""):
> try:
> etype = etype.__name__
> except AttributeError:
> pass
if that's not quite clear, or if anyone has other thoughts on this let me know.
--
Jehiah
On Sun, Dec 14, 2008 at 10:58 PM, Jehiah Czebotar <jeh...@gmail.com> wrote:
> Is there a reason that the WebKit/Application.py code (lines 665-705)
> only handles a few specific types of errors, and doesn't enter the
> error handling code for all unknown errors?
>
> I am working on upgrading to 1.0 and i realized in testing that my
> application logic code that raises a custom error (ie: raise "my
> error") will not trigger the user getting an error page as it isn't a
> class that inherits from Exception. This seems different to me than
> the functionality in the previous version i was using.
>
> I would like to see a call to self.handleExceptionInTransaction for
> all errors, not just for ones that inherit from exceptions.Exception.
>
> --
> Jehiah Czebotar
>
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Webware-devel mailing list
Webware-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/webware-devel
