4 ms·

So you've never written code with a bug? There are other ways to panic in go - concurrent map writes, nil pointer dereference. I'm not saying it should happen,

So you've never written code with a bug? There are other ways to panic in go - concurrent map writes, nil pointer dereference. I'm not saying it should happen, but best practice would be a defensive posture especially when it's effectively zero cost, not hoping for the best.

morelisp 4y ago
> So you've never written code with a bug? No, I write bugs all the fucking time! That's why I want my code to panic, so I know I wrote a bug. If that shit gets stashed away in a 500 response in a Prometheus metric maybe I'll chance to see it three days later. But if the container gets blown away, I'll notice.
- pyth0 4y ago
  If your observability tools aren't firing alarms when that panic happens, you have other problems besides the panic. I would much rather find out about a bug that way vs reports from people that the service is down.
preseinger 4y ago
Crashing the program _is_ the defensive posture. Panics -- concurrent map writes or nil pointer dereferences or almost anything else -- usually mean the program state has become invalid. You can't treat them like errors.
- alexeldeib 4y ago
  Taking my own example - you can both monitor for panics per http request, while preserving SLO for other requests server by the same process. Crashing the program is strictly worse imo, since there are other concurrent requests which will now fail for no reason. I agree unhandled panicking makes sense sometimes. It’s context dependent. Program state is a good argument, but I think it really depends.
- groestl 4y ago
  > usually mean the program state has become invalid. _some_ part of a program's state has become invalid. Probably a variable on the stack. In web servers, almost always a part that becomes very irrelevant as soon as the current request ends. In databases, the same is true at transaction boundaries. In shells it's the REPL. Exit(1) in any of those deep down the stack? No thank you, wouldn't touch that software with a 10 foot pole.

morelisp 4y ago

> So you've never written code with a bug? No, I write bugs all the fucking time! That's why I want my code to panic, so I know I wrote a bug. If that shit gets stashed away in a 500 response in a Prometheus metric maybe I'll chance to see it three days later. But if the container gets blown away, I'll notice.

pyth0 4y ago
If your observability tools aren't firing alarms when that panic happens, you have other problems besides the panic. I would much rather find out about a bug that way vs reports from people that the service is down.

preseinger 4y ago

Crashing the program _is_ the defensive posture. Panics -- concurrent map writes or nil pointer dereferences or almost anything else -- usually mean the program state has become invalid. You can't treat them like errors.

alexeldeib 4y ago
Taking my own example - you can both monitor for panics per http request, while preserving SLO for other requests server by the same process. Crashing the program is strictly worse imo, since there are other concurrent requests which will now fail for no reason. I agree unhandled panicking makes sense sometimes. It’s context dependent. Program state is a good argument, but I think it really depends.
groestl 4y ago
> usually mean the program state has become invalid. _some_ part of a program's state has become invalid. Probably a variable on the stack. In web servers, almost always a part that becomes very irrelevant as soon as the current request ends. In databases, the same is true at transaction boundaries. In shells it's the REPL. Exit(1) in any of those deep down the stack? No thank you, wouldn't touch that software with a 10 foot pole.