Dear forum,
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.
There is another good reason why raising an exception would be a
terrible choice. When SQLite is used as a shared library by some
scripting language, there is /*no*/ possibility to trap exceptions
raised within the library.
This would means that if ever an SQL statement encounters divide by
zero, the application will crash with no way handle the situation
gracefully, nor to locate the source of the problem.
I often see experienced people here completely disregard the contexts
where SQLite is used this way and I find it is a form of myopia (or is
that disdain?). Just because a share of users build applications in
languages like C[++|#], Delphi, Python, Ruby, YouNameIt with SQLite
statically linked or embedded in the language as a standard component,
that shouldn't hide or dismiss different contexts which don't enjoy the
same power.
Returning null may not be the best choice but I don't see that changing
now. Float signed infinity or Nan could be considered, anything but not
an exception.
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.
Exactly!
BTW I often read here that "_sqlite3_get_table is deprecated". This
opinion is common but is very dommageable to future uses in contexts
where calling a shared library comes with a significant time penalty.
This API has been there for very long, is well tested and has proven
reliability. Should it be removed anytime in the future, countless
applications written in some scripting languages will have to replace
it by a loop of multiple calls to the shared library, slowing down
applications dramatically (like 20-fold or more).
Why penalize a share of users and not let this API live in the library
forever, and why not offer its counterpart in SQLite v4?
In general I see SQLite developpers take great care for widenning
potential use contexts of SQLite, not limiting it. Some attention is
requested to what some may call "unusual environments", which are
nonetheless many users everyday's reality.
Thank you.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
