4 ms·

This is my biggest gripe with Go as well. Though initially the diligent programmer will check each and every call with if err != nil {}, there comes a time whe

This is my biggest gripe with Go as well. Though initially the diligent programmer will check each and every call with if err != nil {}, there comes a time when laziness kicks in. When that time comes, you'll get hit with unexpected behavior (aka: tracking down nil references). You might argue the same would happen with exceptions. Yes, they will blow up in your face as well if you fail to catch them. But when they do, you'll hopefully have a well specified restriction that enables to you pinpoint the issue almost immediately. Basically, with exceptions you know the guy who shot you in the gut because you were being lazy, whereas with Go's error system he's hiding behind the bushes with a dozen or so of his conspirators.

Matthias247 10y ago
You can argument around that in both directions: Yes, exceptions will blow your program up and you will see it later on and can debug the exception - no silent errors. But on the other hand what you really want is correct error handling from the beginning (and no blowing up in release builds or SW delivered to customers). Here error return values have the advantage in my opinion that you directly see development that a function can error and that you need to handle that error. While you can't see that a function might throw. What Go is probably missing is forcing you to look at the returned error values while you can currently accidentally miss them by only assigning the first return value of a function.
- atrudeau 10y ago
  Yes, that would be nice, but as lazy programmers we skip some error checks for a reason: sometimes the error is highly unlikely. As such, it might not be worth the cost of writing a bunch of error checking code which costs keystrokes and litters the code with ifs. If an uncaught exeception does happen, it moves from unlikely to likely, and so gets plugged up in the code. Rinse and repeat. Again, the obvious advantage being errors that are easy to track. In go this approach would result in a possibly nightmarish debugging session.
  - Matthias247 10y ago
    Lazy programmers that skip error checks or count keystrokes as a something major are probably at the wrong job. Either an error can happen then it must be handled - no matter how likely it is. Or it can't happen, then there's no need to handle it. The rare exceptions are functions where errors are indicated in the type signature but in reality won't occur, e.g. because the error return value will only be used in other implementations of an interface or because a precondition that guarantees that there will be no error was checked before. And for this cases you could still do something like: _ = functionThatReturnsError() This is the approach that you e.g. have to follow in F#.
todd8 10y ago
IMHO, Handling exceptions well (not too course grained, not masking problems, etc.) takes just as much work as simply dealing with each possible error as it turns up in the go fashion. Lazy programmers are going to mishandle exceptions too.

Matthias247 10y ago

You can argument around that in both directions: Yes, exceptions will blow your program up and you will see it later on and can debug the exception - no silent errors. But on the other hand what you really want is correct error handling from the beginning (and no blowing up in release builds or SW delivered to customers). Here error return values have the advantage in my opinion that you directly see development that a function can error and that you need to handle that error. While you can't see that a function might throw. What Go is probably missing is forcing you to look at the returned error values while you can currently accidentally miss them by only assigning the first return value of a function.

atrudeau 10y ago
Yes, that would be nice, but as lazy programmers we skip some error checks for a reason: sometimes the error is highly unlikely. As such, it might not be worth the cost of writing a bunch of error checking code which costs keystrokes and litters the code with ifs. If an uncaught exeception does happen, it moves from unlikely to likely, and so gets plugged up in the code. Rinse and repeat. Again, the obvious advantage being errors that are easy to track. In go this approach would result in a possibly nightmarish debugging session.
- Matthias247 10y ago
  Lazy programmers that skip error checks or count keystrokes as a something major are probably at the wrong job. Either an error can happen then it must be handled - no matter how likely it is. Or it can't happen, then there's no need to handle it. The rare exceptions are functions where errors are indicated in the type signature but in reality won't occur, e.g. because the error return value will only be used in other implementations of an interface or because a precondition that guarantees that there will be no error was checked before. And for this cases you could still do something like: _ = functionThatReturnsError() This is the approach that you e.g. have to follow in F#.

todd8 10y ago

IMHO, Handling exceptions well (not too course grained, not masking problems, etc.) takes just as much work as simply dealing with each possible error as it turns up in the go fashion. Lazy programmers are going to mishandle exceptions too.