1. 6
  1.  

  2. 6

    Postmodern error handling? Is that like when you can define an error as part of a cultural experience?

    “My program crashed!” “Actually, in some cultures, a crash is a sign of respect. The program just likes you very much!”

    1. 5

      Another take on postmodern error handling: “who are you to say what an ‘error’ is?”

      More seriously, I don’t agree with the tri-state design. I’d still use Either here, with the error type being an algebraic data type of all known errors plus one denoting unexpected errors, mostly because the result of both flavors of errors is analogous, as well as how they are handled.

      1. 1

        Maybe not for this specific case, but I would like a first-class tri-state representation for what I’d call success/failure/error; something analogous to HTTP 2xx/4xx/5xx . Failures are expected to behave consistently and indicate that your request was wrong; errors are expected to be transient and so retrying is probably appropriate. I think a lot of difficulty in error-handling comes of conflating these two classes of problem.

    2. 3

      I’m a fan of named tuples, I love the new f-string formatting, and I like that Python is moving towards some kind of type guarantees (or we’re getting it through mypy), but the kind of error handling the article is talking about is possible in Python 2, and looks basically the same.

      def raises(error_type):
          try:
              raise error_type()
          except SyntaxError:
              print "caught a syntax error"
          except Exception:
              print "caught some other error"
      
      raises(SyntaxError)
      raises(NotImplementedError)