[Python-Dev] Another traceback idea [was: except Exception as err, tb] (original) (raw)

Guido van Rossum guido at python.org
Sat Mar 3 01:30:51 CET 2007

On 3/2/07, Andrew Dalke <dalke at dalkescientific.com> wrote:

On 3/2/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote: > This has given me another idea: ... > Now, I'm not proposing that the raise statement should > actually have the above syntax -- that really would be > a step backwards. Instead it would be required to have > one of the following forms: > > raise ExceptionClass > > or > > raise ExceptionClass(args) > > plus optional 'with traceback' clauses in both cases. > However, the apparent instantiation call wouldn't be > made -- it's just part of the syntax.

Elsewhere here I listed several examples of existing code which raises an instance which was caught or created earlier. That would not be supported if the raise had to be written in your given forms.

Raising an instance that was just caught or created a bit earlier should definitely be supported. Especially this pattern is useful, in all its variations:

def handle_error(self, exc): """Subclass can override to ignore it.""" raise exc

def foo(self): if self.bar(): self.handle_error(RuntimeError("can't foo because of bar")) # if it returns, ignore bar

do foo's thing

The question is, how to distinguish this from an exception created much earlier and raised repeatedly? Adding an attribute pointing to the "owning thread" might help catch concurrent use, but that wouldn't help if the pattern is used in a single-threaded environment, even though it could still be an error there (e.g. in used in a recursive context).

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list