...
If something_really_bad_happens in g(), the function prints an error message to stderr and then calls abort(). The problem is that this application-independent code does not know the context in which it is being called, so it is erroneous to handle the error.
Wiki Markup
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.
...
While this error handling approach is secure, it has the following drawbacks:
Wiki Markup - All function return values must be checked. (See rule MEM32-C. Detect and handle memory allocation errors.)
- Functions should not return other values if they return error indicators. (See recommendation ERR02-C. Avoid in-band error indicators.)
- Any function that allocates resources must ensure they are freed in_cases where errors occur.
...
CERT C++ Secure Coding Standard: ERR05-CPP. Application-independent code should provide error detection without dictating error handling
Bibliography
Wiki Markup
[Saks 2007b|AA. Bibliography#Saks 07b]\]
...