The language’s status quo forces everyone to think about errors more deeply than in other languages and acknowledges that the error case is as critical and worthy of the programmer’s attention.
The language’s status quo forces everyone to think about errors more deeply than in other languages and acknowledges that the error case is as critical and worthy of the programmer’s attention.
x := FallibleFunction() ? err -> return fmt.Errorf("something happened %v", err)
Doesn't really change that, but significantly reduces the amount of noise from error handling boilerplate. And (most importantly to me) reduces the amount of vertical space taken up by error handling code, which makes it easier to follow the happy flow.And while handling errors is important, it is also often trivial, just optionally wrapping the error and returning it up to the caller. I agree it is good for that to be explicit, but I don't think it needs to take up more space than the actual function call.
In my experience, the important error handling code is either at the lowest layer, where the error initiall occurs, or at the top level, where the error is reported to the user. Mid level code usually just propagates errors upwards.
Not really. Rust also forces you think deeply about errors but don't bother you with verbose syntax. I think Swift was also similar.