4 ms·

Here's a non-syntactic suggestion. Could we just patch gofmt to permit this: if err != nil { return nil, err; } as a well-formatted line of go? Make it a

• verdverm 1y ago
  What if I wrap the error? Should that be squashed to one line? What is the heuristic?
  • bccdee 1y ago
    Sure, why not? Let the programmer decide if they want one line or three lines; the tool can permit both. Gofmt is line-length-agnostic—breaking up long lines is already considered to be the programmer's responsibility.
    • verdverm 1y ago
      go fmt already changes one-liner if statements to be multi-line you are proposing changing this, making code look different based on differences of opinions between developers go fmt is actually one of the top rated features of Go, it makes everyone's code look the same, everyone has nitpicks about it, yet by and large it is one of the most loved things about Go. Breaking this is even less likely than changing error handling
      • bccdee 1y ago
        The code already looks different based on different developers' opinions. Gofmt already allows this: fmt.Printf("%s %s %s %s\n", arg1, arg2, arg3, arg4) and this fmt.Printf("%s %s %s %s\n", arg1, arg2, arg3, arg4) and this fmt.Printf( "%s %s %s %s\n", arg1, arg2, arg3, arg4, ) and will not alter any of the above. All I want is similar ambiguity around one-line `if` statements. That's not so crazy.
• mseepgood 1y ago
  How would you set a breakpoint on the error return case?
  • bccdee 1y ago
    You wouldn't. Rust's ? operator doesn't permit that either. If you need to put a breakpoint there, put a line break there.
    • mseepgood 1y ago
      One reason I consider Rust's approach worse than Go's.
  • tubthumper8 1y ago
    Inline breakpoint, the same way you set a breakpoint on an expression in any language
  • zffr 1y ago
    You set a breakpoint directly before this line, and then step forward. If you need the breakpoint to only trigger when there is an error, then you can use a conditional breakpoint that triggers when err != nil
• GoatInGrey 1y ago
  The rub there is that you'll have varying styles in which error handling statements appear in your code. With simplistic instances appearing one way and less simplistic ones appearing similarly or differently depending on where each lands on the complexity spectrum. The idiomatic approach is for all instances to be written in the same way regardless of technical nuances. All of that aside, I've come to learn that passing errors up the call stack without any wrapping or handling is a code smell. It is less than useless for me to attempt setting the value of cell A1 in an Excel sheet to "Foo" and then receive an out-of-range error because the developer made no attempt to even inform me of the context around the error. Let alone handling the error and attempting to correct state before giving up. In my Excel example, the cause of the error was a data validation problem a couple columns over (F or so). The error was legitimately useless in troubleshooting.