[kiitos]

If you allow arbitrary code to terminate the process, then the control flow of the program is effectively non-deterministic, and impossible to model, or even really understand. Software written in this way is fundamentally unreliable.

[morelisp]

Reasoning about control flow is much easier when you have so much less control flow because you just let it crash.

[kiitos]

What an insane way to think about programming.

A service should never crash in response to a runtime error, or any kind of business logic conditional! Crashes are not normal, they signal critical problems and/or programmer errors. A service that crashes in production is a priority-0 bug that needs to be addressed and fixed immediately.

More specifically, if you can't trust that calling a function will always return execution to the call site, then there is no way to build a practical and deterministic model of control flow, and it becomes impossible to manage resource lifecycles.

Consider a network protocol that expects an explicit disconnect/teardown procedure. If your process creates a connection with this sort of protocol, you need to at least try to tear the connection down before terminating the process outright. You can't just yolo kill the client and expect the server to deal with it. And this is just one example among infinitely many possible examples: basically every API that understands a concept of a resource has similar expectations: filesystems, consensus protocols, etc. etc.

[morelisp]

I'll pray for you.

(Consensus protocols are your most bizarre example because they're one of the definitional things that needs to keep working no matter how hard or fast a non-quorum of members dies.)

[kiitos]

Likewise.

[kiitos]

Erlang/OTP expects its processes might crash in response to invalid user input. There, crashing is basically normal and relatively common. In contrast, supervisors like systemd and Docker expect their processes to be generally resilient to bad user input, and to crash only in response to much more critical issues. There, crashing is basically abnormal and uncommon. And assumptions are baked into the entire execution stack of each orchestrator.

Crashing is an error handling strategy only if you know a priori that your code will be running in an execution environment that treats crashes as normal. Such environments are exceptions, not the rule.