[kiitos]

Nope.

Panic isn't an ersatz error reporting mechanism, it's a tool of absolute last resort. Any function or method that can fail should return an error, and should signal failure via that error. Callers that invoke any fallible function or method should always receive, inspect, and respond to the returned error.

[morelisp]

Who said panic should report errors? I specifically said abort…

[kiitos]

Panic doesn't reliably abort the program.

And, in any case, arbitrary code doesn't have the right to abort the program in the first place! Only func main is allowed to terminate the process. Errors in any other context should always be reported to the caller via normal control flow, i.e. return.

[morelisp]

This is exactly the broken view I mean.

[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.

[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.