4 ms·

e followed by down and enter produces the following for me, its downright essential snippet code to be on a single character entry for golang: if err != nil {

e followed by down and enter produces the following for me, its downright essential snippet code to be on a single character entry for golang: if err != nil { return |, err } I can't believe how much I need this, on the one hand I love how error handling is explicit, but also the amount of times I handle an error and just pass it means the above code is used a lot.

erik_seaberg 6y ago
I just want to see f(g(x), h(y)). I’m hoping for an editor that both generates and hides the twelve lines of noise that call g, handle an error, call h, handle an error, call f, and handle an error. I don’t want to write or review that for the same reason that stack frame setup just happens in code that nobody writes or reviews. We could generate Go from some other language, but I can’t assume any team will buy into that.
- PaulKeeble 6y ago
  I agree it this needs to happen. Right now about all you can do is snippet your way through it, it is an incredibly common scenario that go handles really poorly. Java's Checked Exceptions was less invasive and API polluting than this is because at least it didn't get in the way of these types of calls where the error should just shortcut. More importantly in Java you could hide the errors behind a generic RuntimeException if from that point up there was nothing anything could do but generically deal with the error. Panic/Recover is similar but very discouraged for this sort of usage pattern.
- closeparen 6y ago
  I feel this way when writing business logic RPC services, because returning the error to the caller is almost always what you want to do. Recently I wrote something very different, more low level. Rather than handlers it had a number of goroutines looping, selecting, and sending to channels. In this case explicit errors were a lot more useful. If it had been a language with exceptions and I had forgotten a try/catch, it could have killed one of my loops. Not good! This is the kind of use case that fits well for Go. I think it’s a systems glue language that just happens to be friendly enough to invite abuse in mundane backend business logic tasks. But using it that way is setting yourself up for frustration.

erik_seaberg 6y ago

I just want to see f(g(x), h(y)). I’m hoping for an editor that both generates and hides the twelve lines of noise that call g, handle an error, call h, handle an error, call f, and handle an error. I don’t want to write or review that for the same reason that stack frame setup just happens in code that nobody writes or reviews. We could generate Go from some other language, but I can’t assume any team will buy into that.

PaulKeeble 6y ago
I agree it this needs to happen. Right now about all you can do is snippet your way through it, it is an incredibly common scenario that go handles really poorly. Java's Checked Exceptions was less invasive and API polluting than this is because at least it didn't get in the way of these types of calls where the error should just shortcut. More importantly in Java you could hide the errors behind a generic RuntimeException if from that point up there was nothing anything could do but generically deal with the error. Panic/Recover is similar but very discouraged for this sort of usage pattern.
closeparen 6y ago
I feel this way when writing business logic RPC services, because returning the error to the caller is almost always what you want to do. Recently I wrote something very different, more low level. Rather than handlers it had a number of goroutines looping, selecting, and sending to channels. In this case explicit errors were a lot more useful. If it had been a language with exceptions and I had forgotten a try/catch, it could have killed one of my loops. Not good! This is the kind of use case that fits well for Go. I think it’s a systems glue language that just happens to be friendly enough to invite abuse in mundane backend business logic tasks. But using it that way is setting yourself up for frustration.