Hacker News Reader

Comment by bccdee | Hacker News Reader

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 special case somehow.

My only big problem with if err != nil is that it eats up 3 lines minimum. If we could squish it down to 1, I'd be much more content.

View on HN

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.

How would you set a breakpoint on the error return case?

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

Inline breakpoint, the same way you set a breakpoint on an expression in any language

You wouldn't. Rust's ? operator doesn't permit that either. If you need to put a breakpoint there, put a line break there.

One reason I consider Rust's approach worse than Go's.

What if I wrap the error? Should that be squashed to one line? What is the heuristic?

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.

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

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.

Reply on news.ycombinator.com