3 ms·
> This style of if err != nil error-checking is, laughably in my opinion, celebrated as an example of the “simplicity” of go programming. Literally nobody ever
by ilyt 4y ago
> This style of if err != nil error-checking is, laughably in my opinion, celebrated as an example of the “simplicity” of go programming.
Literally nobody ever celebrated having to write 3 lines to return error.
The "simplicity" part is "return error at point of happening, each function have error as last argument so you handle error here and now"
The inept syntax was never liked from the beginning, despise stubborness of Go authors to not provide better alternatives
Rust's Result<T,E> does wholly better job with same context, altho tendency for people to just .unwrap() with no context often puts it back into "bad error messages" territory
- satvikpendem 4y ago> altho tendency for people to just .unwrap() with no context often puts it back into "bad error messages" territory I use Clippy lints for that [0], and a tool called Cranky that makes it easy to use Clippy lints in a project instead of as a command line tool like Clippy normally does [1]. [0] https://rust-lang.github.io/rust-clippy/master/#unwrap_used https://rust-lang.github.io/rust-clippy/master/#unwrap_used [1] https://github.com/ericseppanen/cargo-cranky https://github.com/ericseppanen/cargo-cranky
- valenterry 4y ago> Literally nobody ever celebrated having to write 3 lines to return error. On Hackernews many people say that they like it and it's easy to understand. Maybe celebrate is a bit exaggerated, but I would say Golang is celebrated and the simpleness of errorhandling is often mentioned, so I can see where OP comes from.