Python exceptions considered an anti-pattern

The mistake I see people make is to use built-in exceptions without subclassing, making it impossible to explicitly catch specific errors. Or the opposite, catching Exception, which will catch everything indiscriminately.

> So, the sad conclusion is: all problems must be resolved individually depending on a specific usage context.

Why is that sad/revelatory? If the wrapper simply reproduces the behavior of a single infix operator for floating point numbers, then almost by definition one would need to reimplement NaN in order to get a general purpose exception handler.

> Exceptions are hard to notice

No. In Java they are easy to notice. In Python we have a dynamic language, so there is no safety net for that. It's a limit of the language that we chose, by design, with pros and cons. It's not exception related.

> So, the sad conclusion is: all problems must be resolved individually depending on a specific usage context. There’s no silver bullet to resolve all ZeroDivisionErrors once and for all

That's a good thing. There are many reasons to have a ZeroDivisionErrors, and they beg all for a different solution. Sometime it's you, sometimes it's the user, sometime it's just how things are. Again, it's not related to exceptions in any way.

> For example, the system might notify the user to change the input, because we can not divide by 0. Which is clearly not a responsibility of the divide function

Indeed, you are supposed to sanitize your inputs at the intersection between your program and the rest of the world. No surprise, this has nothing to do with exceptions.

> Now we just need to check where this exception is actually caught. By the way, how can we tell where exactly it will be handled?

Because you write the handling code. If you don't write error code handling, how is that the exception system fault ?

> There’s no way to tell which line of code will be executed after the exception is thrown.

Yes, there is. Either you handle it, and the next step is in the try/except, or you don't, in which case your program crashed. Same with any way of dealing with errors. It's not about exceptions.

> We have two independent flows in our app: regular flow that goes from top to bottom and exceptional one that goes however it wants.

Nope, the exception flow goes from the bottom of the stack to the top. It's well defined, we even have a beautiful stack trace for that. Don't blame exceptions if you don't even know the basics.

> Exceptions are not exceptional

Compared to the rest of the lines of your program, they are. Exceptions are called that way because they represent a special case. The fact computing is full of them is, you know it now, not related to exceptions.

> How to be safe?

Handle the error. Like in any language, with any error handling tool. There is a difficulty in Python: the exceptions are not listed in the function signature. That's hardly the fault of the concept of exception, and is just a design compromise.

> Now you can easily spot them! The rule is: if you see a Result it means that this function can throw an exception. And you even know its type in advance.

So basically you rewrite Java in Python. Again, not a problem with the exceptions. And oh, no, don't do that. If you want that, use Java, not Python. It's perfectly reasonable, but don't turn Python into Java. The fact exceptions are not written in the function signature is, I repeat, a design decision. It has pros. It has cons. But don't use a screw driver like a hammer, that's bad.

> ow to work with wrapped values?

Ok, now you are trying to implement Haskell in Python.

Use Haskell then.

Python is not made for this. It's an easy to write and read language. You are supposed to be able to edit Python code with notepad if you have to. Every line should be short and to the point, with a well defined role.

And we expect exceptions to bubble, that's how we like it.

> But how to unwrap values from containers?

See what I mean ? The author just opened the pandora box. Now he or she has to write long chunks of text just to explain the basic of error handling.

Without this system, I can just pdb.set_trace() in there, now it's full of inlines, chaining, anonymous callbacks and wrappers.

That's just... no.

The key thing to understand here is that post is really about an attempt to implement the "Railway Oriented Programming" paradigm [1] by Scott Wlaschin, but in Python. I would suggest reading the Scott's post on ROP and at least skimming the video before going on.

So ROP is, as Scott himself states, a way to take all those nice Haskell concepts and techniques and apply them in F# in a way that won't overwhelm those who are new to them.

The problem with the original post is that it presents two problems with exception in Python and then offers the "returns" library as a solution which, ultimately, doesn't end up solving either of those problems.

The first problem the post describes is that the exceptions are not part of the function signature. The second problem is that exceptions are essentially gotos and that this makes reasoning about the execution flow very difficulty.

To tackle both problems, the returns library offers its own implementation of the Either monad in form of the Result container. Having presented that solution, the post promptly decides that monadic code in Python is unreadable and offers the @pipeline decorator which allows you to write code that looks imperative, which partially defeats its purpose as a solution to the problem about the flow reasoning. I say partially, because it replaces implicit gotos with implicit returns, which is a marginal improvement over exceptions.

The post then decides that using the Result class in the signature is also ugly and offers the @safe decorator which allows you to write the same code you would write without ROP, but now it wraps everything in Result behind the scenes. Even worse than that, this produces the return type of Result[whatever_your_success_type_is, Exception]. For those familiar with Java, this is very similar to putting "throws Exception" in your method signature, except that it's hidden and implicit.

I'll end this with a bit of advice for the author, preceded by an apology, because I'm not sure if I have managed to find a way of phrasing it that doesn't sound harsh. You might want to do some serious reading about functional programming and monads and how these concepts have been carried over into and grafted onto mixed-paradigm languages like Java. I mention Java specifically, because one of the complaints in your post is that Python won't be supporting checked exceptions in the nearest future. A lot has been written about checked exceptions in Java -- on both sides of the discussion.

[1]: https://fsharpforfunandprofit.com/rop/ [2]: https://en.wikipedia.org/wiki/Tagged_union

"Typing failure modes, not just successful returns" or something would sound like a much more appealing article to a much wider audience.

  def update_password_view(session_cookie):
      values = request_params(['old_password', 'new_password'])
      user = get_user(session_cookie)
      verify_password(user, values['old_password'])
      update_password(user, values['new_password'])
      return 200
  
  def request_params(param_names):
      values = {}
      for key in param in param_names:
          try:
              values[key] = request.params[key]
          except KeyError:
              raise BadRequestError('Missing parameter', key)
      return values
  
  def get_user(session_cookie):
      users = db.get_user_with_session(session_cookie)
      if len(users) != 1:
          raise NotFoundError('No user with that session')
  
      return users[0]
  
  def verify_password(user, old_password):
      if hash(user.old_password) != hash(old_password):
          raise BadRequestError('Bad password')
  
  def update_password(user, new_password):
      user.password = hash(new_password)
      db.update_user(user)

Our actual implementations are more subtle. We have our own exception hierarchy with classes like `UserNotFoundError` or `BadPasswordError` that subclass the corresponding HTTP error classes, so you can still write code like:

  def upsert_user(data):
      try:
          user = get_user_by_email(data.email_address)
      except UserNotFoundError:
          user = User(data)
          db.save(user)
      do_something_with(user)

In practice, we've found this coding style to be much easier maintain than idioms like `if not_found(user): return None` where you spend half your lines of code explicitly checking return values for error sentinels. Life's too short to live like that.

This is why unit-tests are really important in Python.

> We should have language-level mechanisms for being explicit about what's supposed to happen when unexpected situations happen.

That's implemented as a try-except block. You're not supposed to catch errors at the low level unless you're explicitly handling them. If there's an error, bubble it up to the main().

Python's try-except can catch classes, sub-classes, and/or groups (tuples) of classes. It's important to categorize your errors.

    methods = [method1, method2, method3, method4]
    for method in methods:
        try:
            method()
        except Exception:
            pass
        else:
            break
    else:
        raise NoMethodWorked()

    methods = [(method1, TypeError), (method2, KeyError)]
    for m, e in methods:
       try: m()
       except e: ...

    try:
        method1()
        return
    except Exception: # or a more specific exception type
        pass # try the next method
    try:
        method2()
        return
    except Exception:
        pass
    # ...
    try:
        method10()
    except Exception:
        raise NoMethodWorked()

    try:
        DispatchController.dispatch()
    except:
        raise DispatchFailed()