Synopsis: See No Evil

“I found another bug in your product,” the voice on the phone said.

I got this call while working as a technical support engineer for an SQL RDBMS in the 1990s. We had one customer, Mr. Davis, who was well-known for making spurious reports against our database. Nearly all of his reports turned out to be simple mistakes on his part, not bugs.

“Good morning, Mr. Davis. Of course, we’d like to fix any problem you find,” I answered. “Can you tell me what happened?”

“I ran a query against your database, and nothing came back.” Mr. Davis said sharply. “But I know the data is in the database — I can verify it in a test script.”

“Was there any problem with your query?” I asked. “Did the API return any error?”

Davis replied, “Why would I look at the return value of an API function? The function should just run my SQL query. If it returns an error, that indicates your product has a bug in it. If your product didn’t have bugs, there would be no errors. I shouldn’t have to work around your bugs.”

I was stunned, but I had to let the facts speak for themselves. “OK, let’s try a test. Copy and paste the exact SQL query from your code into the query tool, and run it. What does it say?” I waited for him.

“Syntax error at SELCET.” After a pause, he said, “You can close this issue,” and he hung up abruptly.

Mr. Davis was the sole developer for an air traffic control company, writing software that logged data about international airplane flights. We heard from him every week.

Objective: Write less code

Everyone wants to write elegant code. That is, we want to do interesting work with little code. The cooler the work is and the less code it takes us, the greater the ratio of elegance. If we can’t make our work cooler, it stands to reason that at least we can improve the elegance ratio of coolness to code volume by doing the same work with less code.

That’s a superficial reason, but there are more rational reasons to write concise code:

• We’ll finish coding a working application more quickly.

• We’ll have less code to test, document, or have peer-reviewed.

• We’ll have fewer bugs if we have fewer lines of code.

It’s, therefore, an instinctive priority for programmers to eliminate any code they can, especially if that code fails to increase coolness.

Legitimate uses of the antipattern

We can omit error checking when there’s really nothing for us to do in response to the error. For example, the close() function for a database connection returns a status. Still, if our application is about to finish and exit anyway, it’s likely that the resources for that connection will be cleaned up regardless.

Exceptions in object-oriented languages allow us to trigger an exception without being responsible for handling it. Our code trusts that whatever code is called is the code that’s responsible for handling the exception. Our code, therefore, can allow the exception to pass back up the calling stack.