When a library aborts due to some kind of anomaly, it is saying there is no hope for execution to proceed normally beyond the point where the anomaly is detected. Nonetheless, it is dictatorially making this decision on behalf of the client. Even if the anomaly turns out to be some kind of internal bug in the library, which obviously cannot be resolved in the current execution, aborting is a bad thing to do. The fact is, a library developer cannot possibly know the fault-tolerant context in which his/her library is being used. The client may indeed be able to recover from the situation even if the library cannot.
For example, consider a scientific computing client that uses multiple solver libraries. One, say
, is relatively new and untested while another, say
, has been used without error by the client for years. The client may be designed in such a way that if it encounters problems using
, it simply falls back to using
. However, if
aborts due to an anomaly it detects, the client cannot recover. Furthermore, even if there was no
to fall back on, there can be other actions a client might like to take in response to an anomaly in
. For example, after the client has ground out numerical computation for hours, it may wish save its internal state (make a check point) before terminating in response to an anomaly in
. Again, a client cannot do this if a library it uses decides, for any reason, to abort.
For these reasons, a smart library contains no calls to
or the like.