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
