4 ms·
A goroutine created inside an http request handler (itself a goroutine) which then panics, by default will crash the whole server, not the single request. The p
by alexeldeib 4y ago
A goroutine created inside an http request handler (itself a goroutine) which then panics, by default will crash the whole server, not the single request. The panic could simply be an out of bounds access. That should not crash the whole server.
It’s a logic bug, but you can’t “not panic”. You can trap and recover it though.
Bit orthogonal to OP but relevant to your reasoning.
- bxfhjcvu 4y ago[dead]
- morelisp 4y ago> simply be an out of bounds access If you have any care for quality at all, there's nothing "simple" about your invariants being violated.
- alexeldeib 4y agoSo 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 agoIf 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 agoCrashing 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 agoTaking 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.
- gpderetta 4y agoOn a memory unsafe language if you find your invariants violated all bets are off and it is possible that the integrity of the runtime is compromised. The only safe option is to bail out to the nearest protection boundary (i.e. the process). On a memory safe language, the blast radius is potentially much smaller (in principle all objects transitively reachable from the failure point, but this is very pessimistic), so it is realistic to be able to isolate the failure in process.
- preseinger 4y agoWell, memory safety is not a boolean, it's a property that's defined by the memory model of the language. That model also defines the impact of a violation.
- deleted 4y ago[deleted]