[Python-ideas] Re: Introduce 100 more built-in exceptions

On 5/2/2020 7:18 AM, Alex Hall wrote:

On Sat, May 2, 2020 at 12:39 PM Henk-Jaap Wagenaar mailto:wagenaarhenkjaap@gmail.com> wrote:

Of course, there are other ways of writing this code, but imagine this for a database interface where a save normally returns the saved object (inspired by Django)

``` try:     x, y = Foo.save() except ValueUnpackingError:     // oh... this means saving failed (it returned None instead)     // let's return a sensible response     return ExceptionToResponse(FooStateToException(foo.state)) ```

My concern is that this is risky code. If `Foo.save()` has a bug somewhere inside (or maybe it calls back to your own code which has a bug) it could raise `ValueUnpackingError` for different reasons, and then that gets caught and misleads people into thinking that Foo.save returned None which leads to all sorts of frustration and confusion.

This code:

``` result = Foo.save() if result is None:     return ExceptionToResponse(...) x, y = result ```

is not sexy, but it's explicit, safe, and it targets the real problem precisely.

Creating these new exceptions would encourage people to write code that will bite them later.

I agree that we don't want to encourage code like the above example with catching the hypothetical ValueUnpackingError. I contend that even if we added ValueUnpackingError, no one would ever write code that used it, but should instead do what they do now: unpack it after checking it (as Alex's example shows). Of course, that's a horrible API, but sometimes you have to call horrible APIs. The fact that the API is bad doesn't mean we should add a way to handle it poorly. The only reason I'd want it to exist (and I don't) is to see it in the REPL. But for that, there's the exception message and the traceback, so a unique exception for this would be useless to me.

Another example would be an interactive session where you expect an iterable to have 3 entries (say for a 3D space coordinate) and you want to check this specifically:

``` try:     x, y, z = point except ValueUnpackingError:     print(f"point has wrong dimension") ```

where point is an instance of:

``` class Point:     def __iter__(self):         return (float(x) for x in self._internal) ```

The first example made sense, this is too much of a contrived toy example. Why would you write that try/except in an interactive session? How does catching the exception leave you better off than just letting it bubble up and show you a traceback? What are you going to do after now that x,y,z are undefined variables? How did you end up with a point of unknown dimension?

Can you spot here why ValueError would result in significantly different behaviour? ValueError will also catch it if point's internal list contains a bad entry (e.g. a string that does not convert to a float).

I've never caught an exception in the REPL. And even if I wanted to, like the other examples above, you'd want to put the exception around the smallest possible piece of code. What if the each "x" above was an instance of something whose __float__() might raise ValueUnpackingError? class X:     def __float__(self):         a, b = [3.0]         return a You'd be catching a ValueUnpackingError, but the wrong one. Just adding ever finer-grained exception classes doesn't solve any of the problems I've seen given in this thread. That's not to say improvement is impossible, but it will need to be on a case-by-case basis, with examples that show an actual improvement. Eric