> The SQL standard is short-sighted in the sense that if raising exceptions is specified then also an SQL catch mechanism should have been provided. Not really. Every host-language I have used for SQL (COBOL, PHP, C, Python, AutoIt3, Java) has ways to catch exceptions. But ... in order for a host-language to correctly handle a caught exception it needs information and a NULL is just not enough. The one place where a missing SQL catch mechanism is an issue is an abused CLI. Abused? Yes. As its name implies the purpose of the CLI is to interactively execute SQL statements. That means that for every statement and every exception there is someone at the keyboard. Now you can use or abuse the CLI to execute complex multi-statement SQL, but with said CLI lacking any flow-control that is not ideal (there is a limited flow-control when setting *.bail on* which exits a batch CLI after an exception). So similar to host languages SQL exception handling should be done by the CLI, not by SQL. > A good strategy is to check the value before functions like log are called, and then conditionally do something appropriate. Exactly! Cleanup the data before pushing it into any function with restrictions on its parameters. And if the input has not been cleaned let it throw an exception. An exception should be a hint to check your data - sweeping bad input under the carpet by quietly handling NULL is a bad idea.