4 ms·
Explicit error handling isn't the complaint—3 vertical lines of error handling after every function call is. Rust, for instance, started this way and eventually
by __david__ 5y ago
Explicit error handling isn't the complaint—3 vertical lines of error handling after every function call is. Rust, for instance, started this way and eventually introduced the `try!` macro and finally the `?` operator. It's still explicit, it just doesn't fill your screen with unuseful boilerplate.
- preseinger 5y ago> unuseful boilerplate First, ..., err := process(...) if err != nil { return nil, err } is an unfortunately common antipattern. Errors should always be annotated, e.g. ..., err := process(...) if err != nil { return nil, fmt.Errorf("process: %w", err) } The extra lines carry no significant cost -- it's not like reading them imposes a burden versus parsing a single line dense with semantic information. They expose the `return` keyword, which clearly signals a control flow point that is hidden by method chaining and `?`. And it doesn't grant the error control flow special status! These are virtues. I don't see this as unuseful at all. It's fine if you do, of course! But there's not an objective ruling, here.
- cy_hauser 5y agoSo are you manually building a stack trace?
- preseinger 5y agoIn a sense, yes. But the outcome of this process is deliberate rather than mechanical. You choose how much information to expose to callers at each layer. You can display it to users, in a pinch.