Error return values (e.g. go) are better for building large systems where stability & predictability are important (that is, cost to maintain).
Exceptions are better for quickly building systems (that is, cost to build).
Exceptions are much better for large systems. You can define standardised behaviour regardless of where an error occurs. You can let unexpected errors 'bubble up' and be managed in a way that preserves the integrity of the system. You have the flexibility to recover from errors and let errors be silenced.
There is unparalleled flexibility with exceptions. Go's approach is frankly arcane.
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.
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".
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.)
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?
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
}
...
}I get the personal preference one way or another, but can you go into more detail about what specific features one loses with Go's approach?
func (t *Thing) Delete() error {
count, err := db.Delete(t)
if err != nil {
return err
}
if count != 1 {
return errors.New("delete Thing didn't delete 1 row? count: " + string(count))
}
return nil
}And exceptions are not the only thing that do this automatically for you, so this is just flat out horrible design decision.
I deal with systems that contain millions* of lines of C++. Exceptions are killing us. How much larger do we need to get until I can expect to see the advantages?
* I haven't actually counted those lines or even wc -l'd them.