[Python-Dev] PEP 344 (was: with_traceback) (original) (raw)
Guido van Rossum guido at python.org
Sat Mar 3 02:21:04 CET 2007
- Previous message: [Python-Dev] PEP 344 (was: with_traceback)
- Next message: [Python-Dev] PEP 344 (was: with_traceback)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3/2/07, Andrew Dalke <dalke at dalkescientific.com> wrote:
On 3/2/07, Guido van Rossum <guido at python.org> wrote: > So, despite the existence of libraries that pre-create exceptions, how > bad would it really be if we declared that use unsafe? It wouldn't be > hard to add some kind of boobytrap that goes off when pre-created > exceptions are raised multiple times. If this had always been the > semantics I'm sure nobody would have complained and I doubt that it > would have been a common pitfall either (since if it doesn't work, > there's no bad code abusing it, and so there are no bad examples that > newbies could unwittingly emulate).
Here's code from os.execvpe which reraises an exception instance which was created earlier savedexc = None savedtb = None for dir in PATH: fullname = path.join(dir, file) try: func(fullname, *argrest) except error, e: tb = sys.excinfo()[2] if (e.errno != ENOENT and e.errno != ENOTDIR and savedexc is None): savedexc = e savedtb = tb if savedexc: raise error, savedexc, savedtb raise error, e, tb Would the boobytrap go off in this case? I think it would, because a "savedexc" is raised twice.
It shouldn't. This is a requirement for the boobytrap (which is vaporware as yet :-). Perhaps we could allow reraising whenever the existing traceback chain contains a reference to a frame that is an ancestor of (or equal to) the newly raising frame?
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] PEP 344 (was: with_traceback)
- Next message: [Python-Dev] PEP 344 (was: with_traceback)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]