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

[Walter Dörwald]

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 "<stdin>", line 1, in <module>: 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