golang is not a modern language (how old it is is irrelevent), and the people who designed it did not have a proper language design background (their other accomplishments are a different matter).
Having worked on larger golang code bases, and I've seen several times where errors are either ignored or overwritten accidentally. It's just bad language design.
fmt.Println("foo")
And I was referring to accidental ignoring. I've seen variations of the following several times now:
res, err := foo("foo")
if err != nil { ... }
if res != nil { ... }
res, err = foo("bar")
if res != nil { ... }>The following line in golang ignores the error:
fmt.Println("foo")
a := func() error {
return nil
}
a()
go-lint: Error return value of 'a' is not checked (errcheck)
res, err := foo("foo")
if err != nil { ... }
if res != nil { ... }
res, err = foo("bar")
if res != nil { ... }
go-lint: ineffectual assignment to 'err' (ineffassign)That's the issue with the language, there are so many special cases for convenience sake, not for correctness sake. It's obvious why it's excluded, but it doesn't make it correct. Do you want critical software written in such a language?
Furthermore, does that linter work with something like gorm (https://gorm.io/) and its way of handling errors? It's extremely easy to mis-handle errors with it. It's even a widely used library.
Perhaps more fundamental: it’s impossible to accidentally use an uninitialized “success” return value when the function actually failed, which is easy to do in C, C++, Go, etc.
> people who designed it did not have a proper language design background
Irrelevant.
> It's just bad language design.
try { ... } catch(Exception ex) { ... }
The error here is explicitly handled, and cannot be accidentally ignored. Unlike golang where it's quite easy for errors to go ignored accidentally.
Each language has its wonks.
It's not similar to that at all. Without it, the exception bubbles up until it gets caught somewhere, or crashes the program with a useful stacktrace.
With golang, it just goes undetected, and the code keeps running with corrupt state, without anyone knowing any better.
If you care with go, use errcheck.
class Query {
class QueryResult {
Exception error;
Value result;
}
public QueryResult query() {
try {
return doThing();
} catch(Exception e){
return new QueryResult(error, null);
}
}
}
It's about the default error handling method being sane. In exception based languages, an unhandled error bubbles up until it reaches a handler, or it crashes the program with a stacktrace.
Compare to what golang does, it's somewhat easy to accidentally ignore or overwrite errors. This leads to silent corruption of state, much worse than crashing the program outright.
Gorm isn't using the default error handling.
I've seen a bunch of code that does the equivalent of the Java I posted above. Mostly when sending errors across the network.