News for hackers. Stuff that matters.
Re:Go proposal: Leave “if err != nil” alone? by slx26 on Friday June 28, 2019 @01:01PM (#20306413)
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
Re:Go proposal: Leave “if err != nil” alone? by basic6 on Friday June 28, 2019 @01:28PM (#20306730)
Go's opinionated, three line if is part of the problem. A single line if or ternary operator would reduce the line noise.
Re:Go proposal: Leave “if err != nil” alone? by __david__ on Friday June 28, 2019 @01:54PM (#20307025)
Yeah, 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.