41–50 of 69 posts
I'm part of the people who advocate automated testing and insanely high coverage. Does that mean I want to write all tests manually ? No, I use fuzzers, light test code against many autogenerated fixtures and the like, and get no runtime exceptions.
Duck typing means "bad language" for some people, for me it means "freedom".
The interesting bit starts at https://sobolevn.me/2019/02/python-exceptions-considered-an-... , where it introduces a library for wrapping errors in return types, even if it got little to do with the headline. IMHO the article would be stronger with a title about what it presents and without the first half.
"Typing failure modes, not just successful returns" or something would sound like a much more appealing article to a much wider audience.
It amazes me how enduring formulaic it is to single out some particular design tradeoff of a language, draw up some examples of expressing something where that tradeoff creates worse code, and then act like it's some mortal flaw in the language. Python chose untyped exceptions, period. How is this surprising, given that its basis is untyped parameters? If you don't like that, use Java with its checked exceptions. Or…
> 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.
It amazes me how enduring formulaic it is to single out some particular design tradeoff of a language, draw up some examples of expressing something where that tradeoff creates worse code, and then act like it's some mortal flaw in the language. Python chose untyped exceptions, period. How is this surprising, given that its basis is untyped parameters? If you don't like that, use Java with its checked exceptions. Or…
Do you mean unchecked exceptions? Python exceptions are strictly typed, that's core to how they work. An except clause will catch subclasses of the target, so you need to have a custom type for each exception you want to raise in your code. 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, whi…
The Python runtime is dynamically typed. The Python language is untyped.
"X considered harmful" "X" implies "X considered harmful" Thus "X considered harmful" considered harmful "'X considered harmful' considered harmful" considered harmful ... QED
Here is the greatest inconvenience of Python exceptions for me. Say you have to try 10 different methods, and you only need one to work. Then you have to write 10 try...except blocks so that each next block is indented relative to previous. This creates unreadable code and does not scale for say 100 methods. The solution that came to mind is labeling try blocks and referring them in except blocks. For example: try as…
Here is the greatest inconvenience of Python exceptions for me. Say you have to try 10 different methods, and you only need one to work. Then you have to write 10 try...except blocks so that each next block is indented relative to previous. This creates unreadable code and does not scale for say 100 methods. The solution that came to mind is labeling try blocks and referring them in except blocks. For example: try as…
try:
DispatchController.dispatch()
except:
raise DispatchFailed()
It's hyperbolic and frames your position in a way that's likely to create poison. The people without enough experience & knowledge to evaluate your argument critically are likely to end up parroting it and looking like fools. The people who can evaluate your argument critically are going to scrutinize it much more carefully because you've taken an absolutist position.
Unless you have the knowledge & authority to really make such an absolute statement you do yourself and your readers a disservice.