A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2005-March/052209.html below:

[Python-Dev] Re: Rationale for sum()'s design?

[Python-Dev] Re: Rationale for sum()'s design?Nicolas Fleury nidoizo at yahoo.com
Wed Mar 16 02:49:35 CET 2005
Nick Coghlan wrote:
> Guido van Rossum wrote:
>> No, no, no! NO! Never catch a general exception like that and replace
>> it with one of your own. That can cause hours of debugging pain later
>> on when the type error is deep down in the bowels of the += operation
>> (or perhaps deep down inside something *it* invoked).
> 
> 
> Ouch. Obviously, I hadn't thought about that. . .
> 
> Wasn't there a concept floating around some time ago to support 
> exception chaining, so additional context information could be added to 
> a thrown exception, without losing the location of the original problem?

Like that?

try :
     (...)
except Exception, exception:
     # Keep the current exception stack and add information to exception.
     raise Exception(
         'Additional exception info... :\n' +
         sys.exc_info()[0].__name__ + ': ' +
         str(exception)), None, sys.exc_info()[-1]

I made for myself a reraise function that I use a lot for that purpose, 
but it has some limitations.  A standard way to do it would be great.

Regards,
Nicolas

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4