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