Practice 23: Never call abort(), assert()...(Well, almost never, see Practice 24 )

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 libsolvB.a , is relatively new and untested while another, say libsolvA.a , 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 libsolvB.a , it simply falls back to using libsolvA.a . However, if libsolvB.a aborts due to an anomaly it detects, the client cannot recover. Furthermore, even if there was no libsolvA.a to fall back on, there can be other actions a client might like to take in response to an anomaly in libsolvB.a . 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 libsolvB.a . 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 abort() or assert() or the like.