Crashing As A Kind of Failure vs. Crashing As A Separate Concept From Failure

Succeed/fail semantics can be supported with a code library or directly in a programming language. In succeed/fail languages and techniques, predicate operators (e. g. comparisons, such as <=) do not typically return a Boolean value, but rather, they fail the current execution context if the condition is not met. It's possible to code a conjunction of operations and the conjunction succeeds if and only if all the operations succeed. It's possible to code a list of alternatives and the semantics here is that the computer must try alternatives until encountering one that succeeds.

All this can be done in imperative programming, pure functional programming, or logic-based programming (for example, committed-choice concurrent-constraint logic programming, like ToonTalk).

I coded a library that supports succeed/fail semantics in an imperative language and the client code can also be imperative. I decided that if the underlying programming system detects a condition that would usually only arise from a programmer error, I would not treat a case like that as failure, but rather, as a separate concept called a "crash". I provide a slot where a reference to a callback function can be lodged, so that if a run in the library crashes, the outer code that is invoking the library can recover control and deal with the error. I felt that by providing this concept and hook, I was mimicking Erlang's support for having one process supervise one or more other processes and deal with their possibly crashing.

I now feel that separating crashing from failure was an engineering error, that it leads to requiring more programming effort than should be necessary in building, for example, a web server.

Do you have any strong case to make for separating, conceptually, crashing from failure in a technique (or language) supporting succeed/fail semantics?