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