3 ms·

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

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#.

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#.