6 ms·

And here we see why the claim that golang forces users to handle errors is simply not true. Error handling in golang is just badly implemented.

• jlouis 6y ago
  No. Error handling in Go is very explicit since it doesn't alter the control flow of the program through an exception. I'm hesitant to agree this is just a bad implementation, because you will have to make decisions on error paths in any case. If you don't do that, you are just doing bad programming. On the surface, it looks like you want to use exceptions or other control operators for handling this. But after having programmed for more than 20 years, I'm not too sure there is a good solution to this problem. Programs and operations in programs can fail. And you will have to think about these failures eventually.
  • throw_m239339 6y ago
    The point is that Go doesn't force any developer to deal with errors. Its error system isn't better than exceptions. In fact Go doesn't really have an error system (aside from panics), Go errors are purely a convention and no mechanism around it is actually baked into the language. It's exactly like the "good old" return codes in C. Nothing more, this isn't an error system at all. It's primitive. It's just that Go has multiple returns to make it a bit more bearable. > Programs and operations in programs can fail. Yes, and using return codes absolutely does not guarantee you will avoid panics at all. In fact you can use error codes in any other language if it pleases you, because that's not a language construct. The whole "we have exceptions but we don't have exceptions so you shouldn't use panic/recover" dance is just stupid.
    • apta 6y ago
      Weird that you're being downvoted for stating the obvious.
• laumars 6y ago
  Functions with a single return (err) are a problem but generally Go is better at forcing users to handle errors than some languages. It's also true that error handling in Go is generally less sophisticated than some languages. For developers who prefer more sophisticated tooling, Go might appear badly implemented. However that's a preference thing. I hope you can see what I'm doing here; wild generalisations just end up starting flamewars which nobody wins because everyone is using a different yardstick to measure their "correctness".
  • throw_m239339 6y ago
    > Functions with a single return (err) are a problem but generally Go is better at forcing users to handle errors than some languages. Which languages?
  • mst 6y ago
    I am not at all fond of the go aesthetic personally, but given that aesthetic they really do make the most of the trade-offs they've chosen, and all things considered, yeah, within go's style the way error handling works is actually damn good.
  • apta 6y ago
    It's not a preference specifically because golang's error handling is error prone. The things that slide in golang code don't happen in languages with exceptions.
    • laumars 6y ago
      Go has exceptions too however they serve a different use case. Sometimes an error is a problem that should be handled with granular logic and sometimes an error is something that should hard terminate that function and any parent functions until it is captured. The problem with exceptions is that some languages don't surface that a particular function or API might raise an exception so you're often left having to capture all exceptions and having to write generic failure messages hoping that the exception is descriptive (often it isn't). Or worse yet, you fail to capture that exception and end up with your application hard terminating over something that isn't serious to the programs function. This is why err is so widely used in Go; it enables granular logic, makes it clearer where errors are communicated and thus when they need to be handled; and enables developers to escape code or report errors in ways that are more meaningful to those who actually run the application and who might not have the ability to read the code. By more useful error messages I mean something like this pseudo-code function writeLog(message string) { open(CREATE | APPEND, "/var/log/example.log") writeln(message) close("/var/log/example.log") } If you had an exception in open(), writeln(), or close() then how do you report that to the user? What state has the function been left in? Do you have to capture the exception from each function or does some functions not generate an exception (close() probably wouldn't but the others could)? Whereas (again pseudo-code) function writeLog(message string) error { err = open(CREATE | APPEND, "/var/log/example.log") if err != nil { return errors.New("Unable to open log: %s", err) } err = writeln(message) if err != nil { return errors.New("Log open but unable to write: %s", err) } close("/var/log/example.log") // doesn't return an error } It's clear to the end user what specifically has failed, it's clear to the developer which functions can error and ok, the code is a little uglier for it but no more so than many of the other examples handling errors / exceptions (error handling is inherently ugly). This is clearly a bonkers example made up on the spot and it wouldn't matter too much if there was one generic "unable to write to log" message. But the concept described above has proven very useful in larger applications I've written which have needed to handle errors nested several layers deep in a way that's meaningful for end users (as opposed to developers). Now I'm not saying Go got it right nor that other languages haven't solved this in better ways and I'm certainly not trying to advocate that Go's error handling is "good". However it often feels like most of the complaints leveraged against Go's error handling don't really understand the point behind Go's design in the first place or have other missing pieces of information about what can and cannot be done in Go.