Re: [sqlite] DOMAIN new error code

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 17/10/11 02:00, Jean-Christophe Deschamps wrote:
> That's an half-backed solution.  I know of no application which test
> error codes AND THEN test error message _content_ before selecting a
> way to deal with the error.

The application won't but the user the message is displayed to will then
diagnose based on the message and the SQL used.

> The current situation is way too vague and leaves you dry about the
> cause.

A solution is to have an error flag and diagnostics you store somewhere
(best per thread) and set when the error occurs in your code.  In your
wrapper around sqlite3_step you check on its return if the error flag is
set, and if so issue an error and diagnostics in whatever way makes sense.

Consequently you will get rich error information that makes best sense for
your code and will have a considerably easier time diagnosing it.

> I can think of no good reason why it shouldn't make it in the core
> code:

It will end up just as overloaded as SQLITE_ERROR is.

> it costs nothing,

It would have to have added to all the relevant test cases and
documentation.  Every developer using SQLite will have to consider if a
particular situation would result in SQLITE_ERROR being returned or
SQLITE_DOMAIN.  And once this is added every developer till SQLite 4 comes
out would have to go through that cognitive process.  Plus existing error
handling code would need to be looked at and updated in existing code bases.

> it doesn't eat any resource,

It makes switch statements larger, and requires

> it should need no change to the test harness,

Of course it does.  At the very least it would need to be ensured that the
error code passes through correctly, that default error text sticks should
the developer issuing the message not set one etc.

> it covers something that isn't covered yet and can only make life a bit
> less difficult at times.

It would make *your* life a little less difficult in the short term :-)
It incurs a cost on everyone else for no real benefit.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6cUPkACgkQmOOfHg372QRLKQCfbhMT8J4ATKI7L/3udgrn1qu3
XU8AnRI5sHjdKy1VQTd+ETBjWes9QXBl
=9Wtn
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] DOMAIN new error code

[Tim Streater]

On 17 Oct 2011 at 10:00, Jean-Christophe Deschamps  wrote: 

> At least it would gives a fairly good hint as to what to look for and
> where to look.  You know that some extension function was passed an
> out-of-range argument during the course of the last operation.  From
> there, tracking down the culprit is much easier.
>
> Anyway the issue to solve is not "which library issued it" but "what
> extension function in the few last statements could have got invalid
> argument[s]".  The current situation is way too vague and leaves you
> dry about the cause.

With 350 calls in my code to query and exec, this is why I have a wrapper 
around them to include a location code, so that error logging can tell me 
straight away which call had the error and what was the SQL statement it was 
trying.

--
Cheers  --  Tim
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] DOMAIN new error code

[Jean-Christophe Deschamps]

That is the default text for the error code, but your extension should
provide different text.


That's an half-backed solution.  I know of no application which test 
error codes AND THEN test error message _content_ before selecting a 
way to deal with the error.  Most of the times, the application (or 
third-party manager) will get the error code and report the standard 
message from SQLite, sometimes translated into local language via a 
fixed string table (not everyone on Earth reads English).



Adding a new error code won't really help that much.  For example what
happens if someone combines your math library with my Python extension as
you wouldn't be able to tell which is responsible for a SQLITE_DOMAIN.


At least it would gives a fairly good hint as to what to look for and 
where to look.  You know that some extension function was passed an 
out-of-range argument during the course of the last operation.  From 
there, tracking down the culprit is much easier.


Anyway the issue to solve is not "which library issued it" but "what 
extension function in the few last statements could have got invalid 
argument[s]".  The current situation is way too vague and leaves you 
dry about the cause.


I can think of no good reason why it shouldn't make it in the core 
code: it costs nothing, it doesn't eat any resource, it should need no 
change to the test harness, it covers something that isn't covered yet 
and can only make life a bit less difficult at times. 


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] DOMAIN new error code

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/10/11 17:21, Jean-Christophe Deschamps wrote:
> rather than being confronted to the uninformative SQLITE_ERROR "SQL
> error or missing database".

That is the default text for the error code, but your extension should
provide different text.

Adding a new error code won't really help that much.  For example what
happens if someone combines your math library with my Python extension as
you wouldn't be able to tell which is responsible for a SQLITE_DOMAIN.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6bp94ACgkQmOOfHg372QRsSwCfbFOBZtNiS9/yLDFLSgNliV6D
AakAnjwXBV5MRvlbKv5MnOwzdCImXpmd
=NkfC
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] DOMAIN new error code

[Jean-Christophe Deschamps]

I have the need to use some math extension functions.  While testing 
them I found it very difficult to select an informative error code in 
case of a domain error, like sqrt(-1).


Would it be sensible to create a new generic error code in some next 
release for extension functions to report such kind of errors?  It 
would then be easier to track down the source of the issue if such 
error code existed, rather than being confronted to the uninformative 
SQLITE_ERROR "SQL error or missing database".


Returning NULL silently is not the best choice in some cases (math 
functions for instance but it could serve other cases as well), where 
it is desirable to keep the distinction between a NULL argument (here 
returning NULL makes sense) and an out of range argument (here no 
return value makes sense).


SQLITE_MISMATCH, SQLITE_MISUSE and SQLITE_RANGE already exist but have 
precise, completely different meanings and should certainly not be used 
in those cases.


Something like:
#define SQLITE_DOMAIN  27   /* Type, format or domain error in 
extension function */


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users