4 ms·

> I personally think panics/recover at the top can be cleaner, but it seems most disagree Count me among those. At best, panic/recover would be an uglier versi

> I personally think panics/recover at the top can be cleaner, but it seems most disagree Count me among those. At best, panic/recover would be an uglier version of throw/catch with even worse performance. That said, I hope someday Go adds the "?" return-operator that kotlin and Rust use. Won't really change anything besides adding syntactic sugar for an already recommended pattern. But development ergonomics would improve a lot.

mdcfrancis 4y ago
The authors of the encoding/json library thought the same. As a way to exit from deep down in a parse stack it works well especially if you only have limited entry points. https://cs.opensource.google/go/go/+/refs/tags/go1.19:src/encoding/json/encode.go;l=323 https://cs.opensource.google/go/go/+/refs/tags/go1.19:src/en... uses well typed panics.
- nemo1618 4y ago
  The stdlib is not always the best example of idiomatic Go; encoding/json is particularly infamous for having poor performance and awkward APIs. I'm fairly confident that it it was re-written today, it wouldn't use panic/recover.
- paulsmith 4y ago
  It’s a viable alternative to returning error values in a recursive descent parser.
- compsciphd 4y ago
  which was why I used it. I basically had a single entry point (if i remember correctly) something like "match(regex, text)" and hence it made it easier for me to write by just panic at the error location and recover within the match() call than putting if err != null everywhere. Or at least that's what I thought then in terms of cleanliness. in all the production code I've written in go since then, I haven't used panic/recover because its not considered proper. But I'm still a bit skeptical as do think it can make code a bit cleaner when writing a library (I'd 100% agree though that the panic should never escape the library though and only a plain error returned to the caller, i.e. need strong library boundaries for this).
jjnoakes 4y ago
> That said, I hope someday Go adds the "?" return-operator Same here. I think this is my biggest code-reading pain point as a go developer. I'm toying with the idea of playing more with Go+ https://github.com/goplus/gop/blob/main/doc/docs.md#error-handling https://github.com/goplus/gop/blob/main/doc/docs.md#error-ha...

mdcfrancis 4y ago

The authors of the encoding/json library thought the same. As a way to exit from deep down in a parse stack it works well especially if you only have limited entry points. https://cs.opensource.google/go/go/+/refs/tags/go1.19:src/encoding/json/encode.go;l=323 https://cs.opensource.google/go/go/+/refs/tags/go1.19:src/en... uses well typed panics.

nemo1618 4y ago
The stdlib is not always the best example of idiomatic Go; encoding/json is particularly infamous for having poor performance and awkward APIs. I'm fairly confident that it it was re-written today, it wouldn't use panic/recover.
paulsmith 4y ago
It’s a viable alternative to returning error values in a recursive descent parser.
compsciphd 4y ago
which was why I used it. I basically had a single entry point (if i remember correctly) something like "match(regex, text)" and hence it made it easier for me to write by just panic at the error location and recover within the match() call than putting if err != null everywhere. Or at least that's what I thought then in terms of cleanliness. in all the production code I've written in go since then, I haven't used panic/recover because its not considered proper. But I'm still a bit skeptical as do think it can make code a bit cleaner when writing a library (I'd 100% agree though that the panic should never escape the library though and only a plain error returned to the caller, i.e. need strong library boundaries for this).

jjnoakes 4y ago

> That said, I hope someday Go adds the "?" return-operator Same here. I think this is my biggest code-reading pain point as a go developer. I'm toying with the idea of playing more with Go+ https://github.com/goplus/gop/blob/main/doc/docs.md#error-handling https://github.com/goplus/gop/blob/main/doc/docs.md#error-ha...