Why? Keep in mind in go, you almost certainly don't check the type of the error. Why hold python to a hire standard (or the opposite: why don't you pass errors with types in golang, and handle errors of only a particular type or set of types?)
The answer, in both cases, is of course the same: errors are almost always handled in one of two cases: basically at the callsite (either at the callsite or in the parent function), or they are handled in "main" in some form of catchall.
Exceptions are really great for this. You very much don't worry about the things that might be thrown by a child of a child of a child of foo() that you call, because the abstraction shows that you shouldn't care (unless perhaps foo documents explicitly a particular function it throws). You don't need to waste code or mindshare on something you really don't care about. In go however, you do!
Because unless the caller of foo uses a catchall, it may not actually catch the exception raised by bar. Lets say bar opens a file, and callerOfFoo says `except FileNotFoundError:` ... what if bar opens a file that exists with insufficient Permissions? Then it's `PermissionError`, and callerOfFoo won't catch it.
Sure, its possible that callerOfFoo is prepared for that, but my point is, I don't know that unless I check its code.
With python and other exception based languages? I have made hundreds of commits in my lifetime after being surprised that some random 3rd party library throws a nonstandard exception and breaks all sensible control flow that everybody assumed was happening.
Consider a go function foo which returns some value and an error. What can you do with that error? You mention control flow being broken by python and others, but the control flow of
def myfunc():
if foo():
do_a()
else:
do_b()
def myfunc():
try:
cond = foo()
except:
raise
if cond:
do_a()
else:
do_b()
func myfunc() err {
cond, err := foo()
if err != nil {
return err
}
if cond {
do_a()
} else {
do_b()
}
In exception based languages the "pass the error" case is done for you, but if you do want to retry retriable errors, you can actually use a language feature to know that. In go, you have to hope the library creator created an interface (and that all of the possible errors that could percolate up have compatible error-extension interfaces!) that includes some kind of type information, which almost no one does.
You're talking about "sensible" control flow, but go doesn't have it!
https://gosamples.dev/check-error-type/
cond, err := foo()
if errors.Is(err, ErrFooHadTemporaryFailure) {
// retry
} else if errors.Is(err, ErrFooHostOffline) {
// switchFooHost()
} else if err != nil {
// propagate unhandled error upwards
return nil, fmt.Errorf("foo unhandled err: %w", err)
}
What do you mean by creating an error interface? It's a one liner to make a new error case:
var ErrFooHadTemporaryFailure = errors.New("temporarily failure, retry later")How does this compare to error handling in Go?
No, they are not.
func couldFail() error { /*...*/ }
func ohNoes() {
couldFail()
}
This is intended. Error returns are not special; they are just another return value. Error handling by the caller includes "I don't care if there is an error". Yes, in some situations that's a bad code smell. In others, it really doesn't matter. Go puts the responsibility to decide which applies in the hands of the programmer.
To get the same effect in python, I'd have to wrap the call in
try:
couldFail()
except:
passIf I saw the latter Python code in a code review I would squirm. I would scrutinize it very seriously and if there's some really odd case where you really want this, I'd require at least a logger line or a comment to explain why in the world this is desired behavior.
That depends whether the error condition is worth caring about, for a given application, in a given state.
eg. how often do programs check if `printf("something")` actually succeeded?
Probably not very often? But they probably should?
If you're printing something, there's probably a case where you care about that being printed, and if it's not in that case, that's bad?
This also applies to logs too. Just because you're not always looking at the logs doesn't mean they're not important when you need them.
Sure, if you have some chatty logs going through a distributed logging system you might not want to crash the whole thing, and in that case you might want to ignore the exception. But this is a very fringe case.
I prefer this way, but there was one thing I didn't understand until Ned Batchelder taught me, how to layer them:
- https://nedbatchelder.com/text/exceptions-in-the-rainforest....
- https://nedbatchelder.com/text/exceptions-vs-status.html
I didn't have the full mental model until I read that.
Error handling for an API etc usually make the most sense in a central location (some middleware etc) so why would I check that each and every function call was successful.
I do like go, but the error handling is hardly the best thing about it. It’s just different. Neither is wrong.
Yes, but panics are intended to represent an actually exceptional situation, like dereferencing nil, or the machine running out of memory ... things that normally shouldn't happen, and from which the logic cannot easily recover.
> Error handling for an API etc usually make the most sense in a central location (
Which is doable:
if err := couldFail(); err != nil {
return err
}
It also allows the calling function to ignore the mess and hope that something further up the call-chain will deal with it.
Exceptions circumvent the normal control-flow of a program, and that makes code less obvious to follow. When I see foo calling bar() in go, I know where, and if, errors returned by the function are being handled, just by looking at foo.
When I see foo calling bar() in Python, and there is no try-except block in foo, I have no idea what happens to any errors that bar may return. I now have to check everyting that calls foo, which may be multiple other places, each of which could have a different Exception handling, or none, in which case I have to also check all the callers of that caller of foo, etc.
And even if there is a try-except, I have to check whether except catches the correct TYPE, so now I also need to be aware of the different types of Exceptions bar may raise ... which in turn depends on everything that bar calls, and how bar itself handles these calls, etc.
Yes, error handling in Go is verbose. Yes, it would be nice if it offeres a little syntactic sugar to improve that.
But error handling in Go is also obvious.