[Python-Dev] [Python-checkins] cpython: Close #17828: better handling of codec errors (original) (raw)

Walter Dörwald walter at livinglogic.de
Thu Nov 14 14:22:16 CET 2013

On 13.11.13 17:25, Nick Coghlan wrote:

On 14 November 2013 02:12, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 14 November 2013 00:30, Walter Dörwald <walter at livinglogic.de> wrote:

On 13.11.13 14:51, nick.coghlan wrote:

http://hg.python.org/cpython/rev/854a2cea31b9 changeset: 87084:854a2cea31b9 user: Nick Coghlan <ncoghlan at gmail.com> date: Wed Nov 13 23:49:21 2013 +1000 summary: Close #17828: better handling of codec errors

- output type errors now redirect users to the type-neutral convenience functions in the codecs module - stateless errors that occur during encoding and decoding will now be automatically wrapped in exceptions that give the name of the codec involved

Wouldn't it be better to add an annotation API to the exceptions classes? This would allow to annotate all exceptions without having to replace the exception object.

Hmm, it might be better to have the traceback machinery print the annotation information instead of BaseException.str, so we don't get any compatibility issues with custom str implementations.

There's a reason the C API for this is private - it's a band aid fix, because solving it properly is hard :) Note that the specific problem with just annotating the exception rather than a specific frame is that you lose the stack context for where the annotation occurred. The current chaining workaround doesn't just change the exception message, it also breaks the stack into two pieces (inside and outside the codec) that get displayed separately. Mostly though, it boils down to the fact that I'm far more comfortable changing codec exception stack trace details in some cases than I am proposing a new API for all exceptions this close to the Python 3.4 feature freeze.

Sure, this is something that might go into 3.5, but not 3.4.

A more elegant (and comprehensive) solution as a PEP for 3.5 would certainly be a nice thing to have, but I think this is still much better than the 3.3 status quo.

Thinking further about this, I like your "frame annotation" suggestion

Tracebacks could then look like this:

b"hello".decode("uu_codec") Traceback (most recent call last): File "", line 1, in : decoding with 'uu_codec' codec failed ValueError: Missing "begin" line in input data

In fact the traceback already lays out the chain of events. What is missing is simply a little additional information.

Could frame annotation be added via decorators, i.e. something like this:

@annotate("while doing something with {param}") def func(param): do something

annotate() would catch the exception, call .format() on the annotation string with the local variables of the frame as keyword arguments, attach the result to a special attribute of the frame and reraise the exception.

The traceback machinery would simply have to print this additional attribute.

Servus, Walter

Servus, Walter

More information about the Python-Dev mailing list