5 ms·

> I thought that's why it's called "panic". And you are exactly right. The problem is: People are so used to the "exceptions" paradigm from other languages,

> I thought that's why it's called "panic". And you are exactly right. The problem is: People are so used to the "exceptions" paradigm from other languages, when they see "panic-recover" many immediately think "That's the same thing!!" It isn't, because the only VALID usecase for panics is exactly what you describe: unrecoverable error conditions where terminating the program is the best course of action. `panic/recover` used like exceptions is an antipattern, and one of the worst code smells in a Go codebase.

lblume 2y ago
Exactly, same as panic! in Rust. There is a reason Rust was reluctant to add std::panic::catch_unwind at first. The docs thus explicitly mention that (1) it is not a typical exception mechanism and (2) that it might not even catch panics if unwinding is disabled (common for embedded and restricted development).
- kmeisthax 2y ago
  Also (3) there are panics that can't be safely caught, such as stack overflow.
  - jub0bs 2y ago
    There are even panics that are intended as irrecoverable: https://cs.opensource.google/go/x/sync/+/refs/tags/v0.12.0:singleflight/singleflight.go;l=167 https://cs.opensource.google/go/x/sync/+/refs/tags/v0.12.0:s...
the_gipsy 2y ago
You do need to use it, not to handle errors but to avoid it taking down the whole process (and probably sending some logs / alert / monitoring). Which doesn't apply everywhere, but at least in web dev it does: if a request / task panics, you want to abort just that, not the whole server including any other requests / tasks running. Sadly, you need every goroutine to have its own recovery handler. This works well for your general request / task entrypoints, as there should only be one for each kind, but you need to watch out for any third-party libs spawning goroutines without recovery. They will take down your whole server.
- usrbinbash 2y ago
  > if a request / task panics ...and the condition why it panics is not a situation that warrants a crash, then whatever is called upon handling that request is issueing a panic when it shouldn't. The reason why some libs do that anyway is exactly what I describe above: because in many peoples minds panic == exception. That's a logic error in the code and should get fixed. And one of the best ways to make devs fix things, is to let their application crash when something that shouldn't happen happens anyway, because then someone will start complaining why a service is unreachable. TL;DR: If some condition shouldn't crash a process, it has no earthly business causing a panic.
  - the_gipsy 2y ago
    You're conflating unnecessary panics, with how to handle panics. There will always be panics. You don't need to crash the thing to make devs notice, they're not idiots no matter what Rob Pike told you. You can alert and not throw out the baby with the bathwater. Nobody wants panics in their code, even if they're not crashing the whole world.
    - usrbinbash 2y ago
      > You're conflating unnecessary panics, with how to handle panics. I don't think so. If I have to handle a panic, because otherwise my program no longer works, one of 2 things is true in the vast majority of cases: - There is something seriously wrong with the program or its environment, causing it to panic - There is something in the program issueing a panic when really it should return an error In short: there should be no need to "handle panics" Panics are irrecoverable conditions where its preferable for the program to crash rather than continue. If code panicks for any other reason, thats, in my opinion, wrong, and should be fixed. Panics are not the equivalent to exceptions, and error returns exist for a reason. People who don't like that paradigm can always use a language that uses the exception-paradigm.
      - the_gipsy 2y ago
        > People who don't like that paradigm can always use a language that uses the exception-paradigm. FYI the go std library recovers from panics when it spawns goroutines internally, in most cases. All this has next to nothing to do with exceptions. Nobody is saying to use panics to pass errors or any control flow.
vbezhenar 2y ago
panic/recover is the same thing as exceptions. You can avoid them if you want, that's your decision, doesn't change the technical fact.
- usrbinbash 2y ago
  No it isn't. Semantics matter, and using something against the defined semantics of the language is a huge code smell. For example, I could ignore the fact that Python has exceptions, and instead let functions return error values. Would that work? Yes, absolutely, and I have seen Py-Codebases that do this. Is it semantically correct? No, because in python, semantics dictate that error states are handled via exceptions, and that is the expectation everyone has when opening a python codebase. When in Rome, do as the Romans do.
  - xerokimo 2y ago
    That's being idiomatic to a language, not being semantically correct. Result, Either, Expected, all have different names, but their semantics are all the same. Panic and Recover may not be idiomatically used the same way Exceptions are used in other languages, but they share the exact same semantics of implicitly bailing out potentially multiple functions, going up the call stack until we Catch, or well Recover.

lblume 2y ago

Exactly, same as panic! in Rust. There is a reason Rust was reluctant to add std::panic::catch_unwind at first. The docs thus explicitly mention that (1) it is not a typical exception mechanism and (2) that it might not even catch panics if unwinding is disabled (common for embedded and restricted development).

kmeisthax 2y ago
Also (3) there are panics that can't be safely caught, such as stack overflow.
- jub0bs 2y ago
  There are even panics that are intended as irrecoverable: https://cs.opensource.google/go/x/sync/+/refs/tags/v0.12.0:singleflight/singleflight.go;l=167 https://cs.opensource.google/go/x/sync/+/refs/tags/v0.12.0:s...

the_gipsy 2y ago

You do need to use it, not to handle errors but to avoid it taking down the whole process (and probably sending some logs / alert / monitoring). Which doesn't apply everywhere, but at least in web dev it does: if a request / task panics, you want to abort just that, not the whole server including any other requests / tasks running. Sadly, you need every goroutine to have its own recovery handler. This works well for your general request / task entrypoints, as there should only be one for each kind, but you need to watch out for any third-party libs spawning goroutines without recovery. They will take down your whole server.

usrbinbash 2y ago
> if a request / task panics ...and the condition why it panics is not a situation that warrants a crash, then whatever is called upon handling that request is issueing a panic when it shouldn't. The reason why some libs do that anyway is exactly what I describe above: because in many peoples minds panic == exception. That's a logic error in the code and should get fixed. And one of the best ways to make devs fix things, is to let their application crash when something that shouldn't happen happens anyway, because then someone will start complaining why a service is unreachable. TL;DR: If some condition shouldn't crash a process, it has no earthly business causing a panic.
- the_gipsy 2y ago
  You're conflating unnecessary panics, with how to handle panics. There will always be panics. You don't need to crash the thing to make devs notice, they're not idiots no matter what Rob Pike told you. You can alert and not throw out the baby with the bathwater. Nobody wants panics in their code, even if they're not crashing the whole world.
  - usrbinbash 2y ago
    > You're conflating unnecessary panics, with how to handle panics. I don't think so. If I have to handle a panic, because otherwise my program no longer works, one of 2 things is true in the vast majority of cases: - There is something seriously wrong with the program or its environment, causing it to panic - There is something in the program issueing a panic when really it should return an error In short: there should be no need to "handle panics" Panics are irrecoverable conditions where its preferable for the program to crash rather than continue. If code panicks for any other reason, thats, in my opinion, wrong, and should be fixed. Panics are not the equivalent to exceptions, and error returns exist for a reason. People who don't like that paradigm can always use a language that uses the exception-paradigm.
    - the_gipsy 2y ago
      > People who don't like that paradigm can always use a language that uses the exception-paradigm. FYI the go std library recovers from panics when it spawns goroutines internally, in most cases. All this has next to nothing to do with exceptions. Nobody is saying to use panics to pass errors or any control flow.

vbezhenar 2y ago

panic/recover is the same thing as exceptions. You can avoid them if you want, that's your decision, doesn't change the technical fact.

usrbinbash 2y ago
No it isn't. Semantics matter, and using something against the defined semantics of the language is a huge code smell. For example, I could ignore the fact that Python has exceptions, and instead let functions return error values. Would that work? Yes, absolutely, and I have seen Py-Codebases that do this. Is it semantically correct? No, because in python, semantics dictate that error states are handled via exceptions, and that is the expectation everyone has when opening a python codebase. When in Rome, do as the Romans do.
- xerokimo 2y ago
  That's being idiomatic to a language, not being semantically correct. Result, Either, Expected, all have different names, but their semantics are all the same. Panic and Recover may not be idiomatically used the same way Exceptions are used in other languages, but they share the exact same semantics of implicitly bailing out potentially multiple functions, going up the call stack until we Catch, or well Recover.