Hacker News Reader

Comment by cjfd | Hacker News Reader

Yes, pretty much agree with this word for word. It is very, very difficult to refactor a python application in any sort of reliable way. The standard way of error handling in python appears to be to present the user with a stack trace. Very user friendly (not!). Now people will say that, for instance, mypy can help with this. That is true but since projects can be started without type checking chances are that your project was started without type checking and that introducing mypy is somewhere on the backlog and when it comes off the backlog it will be enabled only partially because otherwise there will be too many errors and so on. It is such a garbage programming environment.

View on HN

I couldn’t (and still can’t) believe that non-exceptional situations are considered exceptional. Such as, there not being a way to parse a string into a number and return a value indicating if it was successful or not. With Python everything is an exception. Messy and inelegant. Of course this mess is called “pythonic” so everything is fine…

https://blog.codinghorror.com/exception-driven-development/a...

https://stackoverflow.com/questions/2184935/performance-cost...

Whether or not you agree with it the argument for exception handling, rather than return values, is it lets the code more naturally flow for the successful case. The alternative is go's repetitive

    f, err := fn(...)

if err != nil { ... }

pattern. Which is better is really a matter of taste. To have error handling smattered all over the code seems more inelegant and messy to me.

What? You can return Exceptions instead of raising them. Since the language is dynamic, the caller can introspect.

Personally, from the perspective of a number parsing function, I think being passed an unparseable number counts as an "exceptional" situation- InvalidArgumentError- and I don't care which way it's returned- as an raised exception, or as an error object- as long as it's clearly documented, and the use matches the semantics of the function (NetworkNotAvailable is a better example of an exception where you're want to put something in the exception block)

> parse a string into a number and return a value indicating if it was successful or not.

Eric Lippert had a decent blog post[1] back in 2008 on this titled "Vexing Exceptions" with regards to .NET.

[1]: https://ericlippert.com/2008/09/10/vexing-exceptions/

> The standard way of error handling in python appears to be to present the user with a stack trace.

What do you expect it to do? Silently fail and move on?

No. How about something that is neither "silently fail" or "print a stack trace"? How about something that lets the programmer handle the error?

Yea python should introduce try except.

Python has proper error-handling since 20+ years.

Reply on news.ycombinator.com