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…
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)
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/