I propose a simple split. When you are writing a daemon or background job whose goal is to never ever stop, then exceptions are indeed a minefield of complexity

I propose a simple split. When you are writing a daemon or background job whose goal is to never ever stop, then exceptions are indeed a minefield of complexity. When you are writing a collection of HTTP/RPC handlers, exceptions semantics are almost always correct: whatever goes wrong just needs to bubble up the stack and become a 5XX for the caller. Being able to “handle” without propagating needs to be possible but is rare enough that it should be opt in.