[Python-ideas] Arguments to exceptions

[Steven D'Aprano]

On Wed, Jul 05, 2017 at 03:29:35PM +0200, Matthias Bussonnier wrote:
> Hi all,
> 
> I want to point out that if it's not common to dispatch on values of
> exceptions it might be **because** it is hard to do or to know wether
> an exception will be structured or not.

It "might be" for a lot of reasons. The argument that "if Python did X, 
we might find a use for X" could be used to justify any idea at all, 
regardless of its usefulness.

I found your post ironic -- after spending many paragraphs complaining 
that exceptions aren't structured enough, that people won't write 
structured exception classes or make use of structured exceptions "if 
it's not encouraged by the core" (your words), you then run a grep over 
your code and find (by my rough count) nearly 100 examples of structured 
exceptions.

So it seems to me that third party libraries are already doing what you 
say they won't do unless the core exceptions lead the way: providing 
structured exceptions. Just a handful of examples from your grep:

> gh-activity/ghactivity.py:                 e.repo
> pypi/store.py:                             e.code 
> cpython/Lib/nntplib.py:                    e.response
> cpython/Lib/runpy.py:                      e.name
> jupyter_client/jupyter_client/manager.py:  e.winerror
> jupyterhub/jupyterhub/utils.py:            e.code
> qtconsole/qtconsole/console_widget.py:     e.mimeData
> xonsh/xonsh/execer.py:                     e.loc
> django/django/forms/fields.py:             e.error_list
> django/django/http/multipartparser.py:     e.connection_reset
> cpython/Lib/asyncio/streams.py:            e.consumed
> ipyparallel/ipyparallel/client/client.py:  e.engine_info
> jedi/jedi/api/completion.py:               e.error_leaf

and more. Third parties *are* providing rich exception APIs where it 
makes sense to do so, using the interface encouraged by PEP 352 (named 
attributes), without needing a default "StructuredException" in the 
core language.


> If Exceptions were by default
> more structured, if CPython would provide a default
> "StructuredException",

As I said earlier, perhaps I'm just not sufficiently imaginative, but I 
don't think you can solve the problem of providing better structure to 
exceptions with a simple hack on BaseException. (And a complicated hack 
would have costs of its own.) I've come to the conclusion that there's 
no substitute for tackling each individual exception class individually, 
deciding whether or not it makes sense for it to be structured, and give 
it the structure needed for that exception.


> or were the norm because CPython would use
> more of them –  then you might see more use case, and new code
> patterns.

And you might not. You might spend hours or days or weeks adding bloat 
to exceptions for no purpose. That's why we typically insist on good 
use-cases for new features before accepting them.

If we accepted even 10% of the ideas proposed, Python would be a 
bloated, inconsistent, hard to use mess.

(Actually I plucked that number out of thin air. It would be an 
interesting project to look at what proportion of ideas end up being 
accepted.)




-- 
Steve