You are 100% right, it is terrifyingly flexible. There is a reason exceptions as flow control is considered an anti-pattern.
Go's error handling approach is also flow control. You receive an error and have to go and do something different based on that error. With Go it is explicit. With say Java you have the choice of being explicit or implicit. Flexibility is vital when you are working on large applications where the business logic varies wildly throughout the system.
Just so. You think something being used in enterprise is a worthy argument?
That doesn't mean Go's "error handling" is any better.
It's probably the worst approach one can pick. (But this has been discussed dozens of times already and Go fans have decided that they don't want to hear it.)
At the "Bank of Golang" though - they've made every customer get strip searched on their way in because of something that happens 1% of the time. No thanks. I'd rather go across the street where they simply have some cameras and security guards watching the crowd for exceptional behavior.
There is slight difference between "the database is on fire" and "a user with user id 42 couldn't be found in the database", don't you think?
Go handles neither of these situations gracefully.
void SomeHighLevelMethod() {
...
catch (const DatabaseOnFireException& e) {
// TODO log something here
// TODO do something here
}
...
}Rust and Swift designers picked a similar approach. Is it possible that three separate designers of languages are so bound by language trends that they decided to make the almost exact same mistakes?
Explicit is way better than implicit by an order of magnitude. It means you can look at any Go code and instantly understand what the control flow will be. You can't do that with languages that have exceptions.
>> At any point in a function, you can suddenly jump...
That's kind of the point. There's a separate path for exceptional behavior, which is what makes reasoning about exception paths easier.
>> It's certainly possible to write correct programs with exceptions, but it's quite hard, and almost no one does it correctly.
You keep saying that, but where's the proof that Golang programs are any more "correct"? How exactly are you quantifying that?
>> Explicit is way better than implicit by an order of magnitude.
That's like saying that having to think about putting one foot in front of the other is better than just walking down the street. It's rather ridiculous to say that.
>> It means you can look at any Go code and instantly understand what the control flow will be.
Not at all because your control of flow is now so concerned with error handling that you can't see the intended "happy path" logic.
f, err := os.Open(filename)
if err != nil {
return fmt.Errorf("failed to open config file: %s", err)
}
// happy path
File f;
try {
f = File.Open(filename)
}
catch (Exception e) {
throw new Exception(String.Format("failed to open config file: %s", e.Message))
}
// happy path
What most people do, is they would let this function throw FileNotFoundException, and not catch it. There's at least three problems with that:
1. It leaks your implementation, so if later you're saving to memcache, you'll throw some different error, which could break consumers that have written code to handle the FileNotFoundException
2. It lacks context: file not found: foo.yaml ... wtf is foo.yaml and why was this random function trying to open it?
3. You can't tell programmatically what failed. Something threw a filenotfound... but you don't know if it was opening the config file or some other function, so you can't handle it properly.
There's also the fact that now anyone who calls your function needs to wrap it in a try/catch, or let an exception from 2 levels deep bubble up. So you can get FileNotFound: foo.yaml from your Initiate() function, and no one knows what that means.
That's what I mean by "almost no one [handles exceptions] correctly".