Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Missing Error Checks
The final easy ways to spot bad code are calls to library functions that fail to perform an appropriate action when the function returns with an error. In C code, errors are often passed from the API to the program in-band, that is together with the function’s result: a special value, like NULL or a negative integer, is used to indicate that the result is not an entity the caller would expect to be returned, but an indication of an error. If the program fails to check the return value of, say fopen or malloc, for NULL, then you can be almost sure there will be situations where the program will crash on the face of its hapless end user. In the Java and .NET platforms, errors are typically communicated out of band through exceptions. In these cases dodging an error situation requires a bit of explicit effort: an empty exception handler. Despite this, I’ve often encountered them in sloppily written code and they are typically bad news.
Handling errors is difficult because the actions one can take after the error occurs are rarely able to rectify the error. Thus, we programmers are put in a position where we have to tediously check one possible error after another, only to report it and exit gracefully. Nevertheless, programs that do not check for API errors reek of unprofessionalism and are often untrustworthy.