| Exactly. Besides, I fail to see how exceptions are the problem in there. > 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. |
Maybe, but there are ungodly big and crufty codebases in Python all around the world, and a lot of stuff depends on them. And it turns out that Python was never meant to be the thing that is being depended on. That's unfortunate. Hence the whole gradual typing (mypy) and other kinds of safety efforts.
You're not forced to use this. But it seems pretty useful, even for scripts.