5 ms·

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 err

by cjfd 3y ago

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.

lloydatkinson 3y ago
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/amp/ https://blog.codinghorror.com/exception-driven-development/a... https://stackoverflow.com/questions/2184935/performance-cost-of-coding-exception-driven-development-in-java https://stackoverflow.com/questions/2184935/performance-cost...
- fragmede 3y ago
  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.
- justcool393 3y ago
  > 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/ https://ericlippert.com/2008/09/10/vexing-exceptions/
- dekhn 3y ago
  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)
PurpleRamen 3y ago
> 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?
- AnimalMuppet 3y ago
  No. How about something that is neither "silently fail" or "print a stack trace"? How about something that lets the programmer handle the error?
  - peteradio 3y ago
    Yea python should introduce try except.
  - PurpleRamen 3y ago
    Python has proper error-handling since 20+ years.

by cjfd 3y ago

lloydatkinson 3y ago

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/amp/ https://blog.codinghorror.com/exception-driven-development/a... https://stackoverflow.com/questions/2184935/performance-cost-of-coding-exception-driven-development-in-java https://stackoverflow.com/questions/2184935/performance-cost...

fragmede 3y ago
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.
justcool393 3y ago
> 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/ https://ericlippert.com/2008/09/10/vexing-exceptions/
dekhn 3y ago
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)

PurpleRamen 3y ago

> 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?

AnimalMuppet 3y ago
No. How about something that is neither "silently fail" or "print a stack trace"? How about something that lets the programmer handle the error?
- peteradio 3y ago
  Yea python should introduce try except.
- PurpleRamen 3y ago
  Python has proper error-handling since 20+ years.