On 16 Sep 2014, at 1:23am, James K. Lowden <jklow...@schemamania.org> wrote:
> Whether or not something "is an error" is a matter of definition. > SQLite defines division by zero to be NULL. It's very unusual in that > regard. MySQL does it too unless ERROR_FOR_DIVISION_BY_ZERO mode is enabled: <http://dev.mysql.com/doc/refman/5.0/en/arithmetic-functions.html> SQL Server does it too unless SET ARITHABORT is ON: <http://technet.microsoft.com/en-us/library/aa259212(v=sql.80).aspx> PostgreSQL doesn't do it, and that annoys some people: <http://www.postgresql.org/message-id/a7342e85-e1df-4411-8d0c-0b76a1b3a...@gtwm.co.uk> > It's also unhelpful because the NULL can mask an error in the > data or logic. I hope SQL 4.0 will define it as an error instead. I would rather it didn't because it's yet another thing to look for and trap in your code, and it's one that most people will not think of most of the time. It expands the test suite. It expands your software. NULLs propagate harmlessly downstream. You display or print them and they appear as something blank or "NULL" or otherwise weird. If a user finds a field unexpectedly NULL, they can figure out what the source of the problem is and correct the data at their leisure. The rest of the program continues to function. Errors crash the program. Start it up again and it might just crash again. Or it might crash again some unpredictable but inconvenient time in the future. And as a user you can't put it right because each time you open the window where you can type the correct data in, the program crashes. You need the help of the developer. At 5:30pm the day before The Big Report is due. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
