
The Dark Path, Or, What If I Don't Want to Quit My Job? - crux
http://blog.zdsmith.com/posts/the-dark-path-or-what-if-i-dont-want-to-quit-my-job.html
======
wyldfire
> This is rather absurd and I won’t address it any more than to point out that
> many ordinary programmers intuitively grasp the basic value of safety and
> specificity, which is why in Python it is widely considered extremely bad
> practice to write `except:` or `except Exception:` even though having to
> specify all of the exception classes we are interested in is arguably a
> safety that we could override at no loss of expressiveness.

It takes me a while to unpack this sentence. So I hope I'm misunderstanding. I
think he's saying that we could skip out on specifying the exception classes
we're interested in without losing expressiveness. Expressiveness aside, this
is a huge change in functionality.

IMO Python probably should've put some kind of damper on `except:` because
it's almost never what you want. First off, I'd call this list of classes ones
we're "prepared to handle" rather than "interested in." `except:` states
boldly "nah, don't propagate this up the stack, I know what to do no matter
what happened down there." Using `except:`/`except Exception:` is bad because
it will catch "UnboundLocalError", "IndentationError" and several others that
are very-nearly unhandle-able elements of the code's design. There exists a
sliver of a case for a handler in __main__() or somewhere else that can log
something though.

If he's getting at the point of Bob's article regarding static typing and
testing, then I don't see how Python be anything like how it is today and
still have some kind of static evaluation of Exceptions-that-could-come-from-
this-call.

