This discussion is going nowhere. And the simple reason is that **both sides** of the argument **are correct**. Yes, the SQL standard says that an invalid argument should raise an exception. Is this 'incorrect'? Is this 'overly paternalistic'? Perhaps, but it is the standard. Yes, you can catch a NULL using coalesce(). But dealing with it? If you expect NULL then there is no problem, but getting NULL when you do not expect this is the equivalent of *'one of the parameters handed to this function is wrong; good luck figuring out which one and why'*. I was facing a similar decision a while ago when writing an extension for calendar calculations: do I raise an exception or is NULL better? Some of the functions involved have four parameters - getting NULL as a result was unworkable. The solution? **Do not make a decision**. The extension now checks for an environment variable SQLITE3_TCAL_ERRORS during initialisation. If this variable exists any function in this extension when confronted with a bad parameter raises an exception with a detailed message telling which parameter was wrong and why. If this variable does not exist the same error results in a NULL. I suggest a similar solution for this problem (maybe using a pragma). As the currect behavior is returning NULL that should be the default and for those of us that require the SQL standard (or are still debugging a query) that would also be possible.