[Python-ideas] Arguments to exceptions

[Ken Kundert]

Nick,
    I see. The Python C interface provides a very simple way of raising an 
exception in the case where the exception is only passed one argument, the error 
message. It even makes it easy to interpolate arguments into that error message.  
If it is important to include other arguments, as with OSError, one would 
presumably use another mechanism that requires more effort.

Your suggestion of providing an alternative to PyErr_Format() that squirreled 
away its arguments into the exception and deferred their interpolation into the 
error message seems like a very nice approach. But as you say, it does not seem 
trivial to implement in C. If it could be extended to support named arguments, 
it does have the benefit that it could unify the way exceptions are raise from 
C.

The alternative would be to simply enhance the individual exceptions on an as 
needed basis as you suggested earlier. That could be easy if the exceptions are 
only raised in one or two places. Do you have a sense for how many places raise 
some of these common exceptions such as NameError, KeyError, etc.?

-Ken


On Sun, Jul 16, 2017 at 02:18:40PM +1000, Nick Coghlan wrote:
> On 16 July 2017 at 10:12, Jeff Walker <jeff.walker00 at yandex.com> wrote:
> > Sorry Stephen (and Steven). I'll do better next time.
> >
> > The way I see it there are two problems, and the second causes the first.
> >
> > The first problem is that there is no direct access to the components that make up the error in some of the standard Python exceptions.
> >
> >     >>> foo
> >     Traceback (most recent call last):
> >         File "<stdin>", line 1, in <module>
> >     NameError: name 'foo' is not defined
> >
> > If you need access to the name, you must de-construct the error message. To get direct access to the name, it would need to be passed to the exception when raised. Why wasn't that done?
> 
> Ease of implementation mainly, as PyErr_Format is currently the
> simplest general purpose mechanism for raising informative exceptions
> from the C code:
> https://docs.python.org/3/c-api/exceptions.html#c.PyErr_Format
> 
> All the more structured ones currently require expanding the C API to
> cover creating particular exception types with particular field values
> (the various PyErr_Set* functions listed on that page).
> 
> That does prompt a thought, though: what if there was an f-string
> style "PyErr_SetStructured" API, where instead of writing
> 'PyErr_Format(PyExc_NameError, "name '%.200s' is not defined",
> name);', you could instead write 'PyErr_SetStructured(PyExc_NameError,
> "name '{name:.200s}' is not defined", name);', and that effectively
> translated to setting a NameError exception with that message *and*
> setting its "name" attribute appropriately.
> 
> The key benefit such a switch to f-string style formatting would
> provide is the ability to optionally *name* the fields in the
> exception message if they correspond to an instance attribute on the
> exception being raised.
> 
> Actually implementing such an API wouldn't be easy by any means (and
> I'm not volunteering to do it myself), but it *would* address the main
> practical barrier to making structured exceptions more pervasive in
> the reference interpreter.
> 
> Cheers,
> Nick.