Swallowing errors is not a good practice in software development. But it is often done because it’s the least path of resistance. What do I mean by Swallowing errors? Most of you understand this term. For those of you who haven’t heard this phrase, Swallowing Errors is the technique where we capture errors, do nothing with them, and allow the program to continue execution using some default or arbitrary path.
Visual Basic was notorious for having error swallowing code. The language allowed you to easily bypass errors by writing the line
ON Error Resume Next
Placing this statement at the beginning of a method of subroutine would cause the program to simply go to the next statement even if the previous statement resulted in an error. The error raised by the program was simply ignored.
I’ve seen the same kind of code written in C# and Java, just to be fair. All you have to do is have a Try/Finally without a catch, and the error is politely ignored. Unlike the Visual Basic code, the program did not resume execution on the next line of code. It falls out of the currently executing context, and then follows the flow after the error handling block. So, while this is somewhat better, it is still lacking in depth. At a minimum, I would expect you would log the error.
Only when you want to test for something that would be an error, and perform a task based on that error, does it make sense to have a try/catch or try/finally and not do something with the error. For example, if you were trying write some code that would test if an object contained an integer value in a string property, you could attempt to convert the string to an integer in a try, and return a true Boolean value if it converted successfully, and false value from the catch if it did not convert. This is a contrived example, because there are already routines to do this kind of thing.
I was prompted to write this editorial based on a blog I read regarding some of the error swallowing built into MySql. I can’t find a date on this blog, so I don’t know how current it is regarding the different code bases branched off MySql.
The thing that caught my attention was the number of behaviors, many of which are trivial, resulting in swallowed errors, relying on default handling of errors in ways that users may not expect. Data conversion was a big one, where it automatically converts data types in ways that are not intuitive, and does not throw errors. Most SQL dialects won’t convert a string to a number. You have to cast the value, and in so doing, you know your intention. MySQL will cast a string to an INT, but, you may not get what you expect. For example, you can implicitly cast the string ‘BANANNA’ to an int. What do you thing that converts to? I don’t know, and to me it doesn’t matter. That should simply throw an error.
There were other behaviors where incomplete aggregate queries return results instead of throwing errors. For example:
SELECT a, b, Count(1) FROM MyTable GROUP BY a
This query works according to the blog, and the results you get for column b in the query are arbitrary. It should simply throw an error like all the other versions of SQL with which I have worked, saying b can’t be included unless it has an aggregate function or is included in the GROUP BY clause. I haven’t used all SQL engines, and there may be some supporting this syntax. But, they shouldn’t. I’d prefer the engine to let me know that I have written a bad query so I can fix it. Don’t let me get by with my mistakes.
Two things to take away from this editorial:
- When using MySql, you need to be aware of its behavior, and areas where it handles errors for you implicitly. You have to be more aware, because the engine won’t always provide you with expected results.
- Don’t write code like this yourself.
Cheers,
Ben