[morelisp]

> Any method or function which is not guaranteed to succeed by the language specification should, generally, return an error.

Most Go programmers are too scared to panic and abort when invariants are violated. I think most codebases contain at least 2x as much error handling as is really necessary.

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