From: Jehiah C. <je...@gm...> - 2008-12-15 03:58:45
|
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 |
From: Jehiah C. <je...@gm...> - 2008-12-15 08:02:24
|
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 <je...@gm...> 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 > |
From: Christoph Z. <ci...@on...> - 2008-12-15 08:35:20
|
Jehiah Czebotar schrieb: > 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. Good suggestion. I will add a test that raises a string exception and fix these problems (there may be some more). You can also upload a patch here: http://sourceforge.net/tracker/?group_id=4866&atid=304866 -- Christoph |
From: Christoph Z. <ci...@on...> - 2008-12-15 08:19:40
|
Jehiah Czebotar schrieb: > 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. The reason is that catching all exceptions would also catch system exceptions such as SystemExit and KeyboardInterrupt which we do not want the application to handle as normal errors. It has been recommended for a long time already that all exceptions (that should not be handled at top level) should inherit from Exception. This is now even required in Python 3.0. String exceptions such as raise "my error" are even worse, they are already forbidden in Python 2.6. I agree with you that Webware 1.0, since it tries to be very backward compatible, should also catch other exceptions, but unfortunately, nobody ever complained about the new behavior that was already in 0.9.3 and 0.9.4, so it stayed in 1.0. Anyway, I will fix that in the 1.0 branch, i.e. catch everything and filter out and reraise the top level exceptions manually instead of using the "except Exception:" idiom. But to make your app future-proof I recommend that you replace every occurence of raise "string" in your app with raise Exception("string") and let all your exceptions inherit from Exception as the base class. -- Christoph |
From: Jehiah C. <je...@gm...> - 2008-12-15 08:31:14
|
thanks for the response Christoph. Inheriting from Exception is probably good advice, and i'll just patch my version of webware to handle things differently as i audit my code to make updates to exception handling. that's probably what i get for trying to update to version 1.0 straight from a 6 year old version of trunk. =) no need to change the functionality on my account; especially if it was there in recent versions... perhaps mentioning this on the list will helps someone else in the future. -- Jehiah On Mon, Dec 15, 2008 at 3:19 AM, Christoph Zwerschke <ci...@on...> wrote: > Jehiah Czebotar schrieb: >> 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. > > The reason is that catching all exceptions would also catch system > exceptions such as SystemExit and KeyboardInterrupt which we do not want > the application to handle as normal errors. > > It has been recommended for a long time already that all exceptions > (that should not be handled at top level) should inherit from Exception. > This is now even required in Python 3.0. String exceptions such as raise > "my error" are even worse, they are already forbidden in Python 2.6. > > I agree with you that Webware 1.0, since it tries to be very backward > compatible, should also catch other exceptions, but unfortunately, > nobody ever complained about the new behavior that was already in 0.9.3 > and 0.9.4, so it stayed in 1.0. Anyway, I will fix that in the 1.0 > branch, i.e. catch everything and filter out and reraise the top level > exceptions manually instead of using the "except Exception:" idiom. > > But to make your app future-proof I recommend that you replace every > occurence of raise "string" in your app with raise Exception("string") > and let all your exceptions inherit from Exception as the base class. > > -- Christoph > |