4 ms·
yeah, I kinda agree. at least in Ruby, besides the errors bubbling up, if you had to handle the error manually, you could use the truthiness of the language to
by slx26 7y ago
yeah, I kinda agree. at least in Ruby, besides the errors bubbling up, if you had to handle the error manually, you could use the truthiness of the language to write just:
do_something if err
I've read the other proposals, and in fact one of them (catch) is similar to what I do when I'm coding just for myself:
value, err := os.Open(filename)
exit_on_error(err)
where the code for exit_on_error is simply something like:
if err != nil {
fmt.Println("Something went wrong!")
os.Exit(1)
}
you could make it a bit more robust:
value, err := os.Open(filename)
handle_error(err, ERROR_FILE_OPEN)
where ERROR_FILE_OPEN could be a simple constant, and in the method we have a switch with constants and messages. not a zero cost abstraction, but if you have to handle an error, it probably wasn't a cheap operation either, so the extra call won't be an issue
- basic6 7y agoGo's opinionated, three line if is part of the problem. A single line if or ternary operator would reduce the line noise.
- __david__ 7y agoYeah, it's quite common in C to just do: if (error) return error; It's the same style as go, but so much more compact. If `go fmt` were to render the error boilerplate as if err { return err } …instead of the three line boilerplate it insists on, then it would go a long way. That said, I still support `try()`. It looks good to me, especially coming from Rust.