PEP 317: Eliminate Implicit Exception Instantiation

Bernhard Herzog bh at intevation.de
Tue Jun 10 04:45:49 EDT 2003


Steven Taschuk <staschuk at telusplanet.net> writes:

> Quoth Bernhard Herzog:
>   [solicited example of use of traceback argument to raise]
> >         except SketchLoadError, value:
> > 	    raise SketchLoadError('%d:%s' % (self.lineno, str(value))), None,\
> >                   sys.exc_traceback
> > 
> > So, basically it's there to put some more information into the error
> > message. Not all places where SketchLoadError is raised have access to
> > the line number so it can't easily be done in other ways.
> 
> Yes, this makes sense.  It seems to me a bit odd to create a new
> exception object, though; would it work to mutate the existing
> SketchLoadError and re-raise it?

In this particular case, yes. There are other cases where the exception
type is different too, but I'm not sure anymore whether that really is a
good idea.

> > threads so it shouldn't be a problem unless somebody now goes and starts
> > deprecating sys.exc_traceback ;-)
> 
> It's been deprecated since 1.5 according to the Library Reference.
> <wink>

Yes, but Python doesn't issue warnings about it. Actually, issuing
deprecation warnings for exc_traceback and friends might be a good idea.
The alternative has been available since 1.5 and it is a potential
source of bugs. It would be far less controversial than the proposed
syntax change for the raise statement, I think.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                           http://www.mapit.de/




More information about the Python-list mailing list