Webware for Python

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 <jehiah@...> 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
>

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

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 <cito@...> 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
>

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