...
| Wiki Markup |
|---|
\[[Miller 04|AA. References#MillerBibliography#Miller 04]\] Practice 23 says: |
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.
...
Wiki Markup Source and object code can significantly increase in size, perhaps by as much as 30 to 40 percent \[[Saks 07b|AA. References#SaksBibliography#Saks 07b]\].
- All function return values must be checked (see MEM32-C. Detect and handle memory allocation errors).
- Functions should not return other values if they return error indicators (see ERR02-C. Avoid in-band error indicators.)
- Any function that allocates resources must ensure they are freed in_cases where errors occur.
...
| Wiki Markup |
|---|
\[[Miller 04|AA. References#MillerBibliography#Miller 04]\] \[[Saks 07b|AA. References#SaksBibliography#Saks 07b]\] |
...