Show numeric code instead of UNKNOWN_ERROR

[mdavidsaver]

Helps in interpreting extended error codes which aren't included in the current SQLiteErrorCode.

In my case, allowed me to discover that

... org.sqlite.SQLiteException: [UNKNOWN_ERROR] unknown error (attempt to write a readonly database)

was really

... org.sqlite.SQLiteException: 0x608 (attempt to write a readonly database)

aka. SQLITE_READONLY_DIRECTORY because while my DB file was writable, the directory was not...

[gotson]

@mdavidsaver can you check the failing CI?

[gotson]

Seems formatting only, you can use the Spotless plugin: mvn spotless:check and mvn spotless:apply

[mdavidsaver]

Seems formatting only, you can use the Spotless plugin: mvn spotless:check and mvn spotless:apply

Done.

[gotson]

I have 2 questions:

1. why display the code as 0x608 while the SQLite website display them as decimal, like 1544 ?
2. could we also include more error codes in SQLiteErrorCode ?

[mdavidsaver]

fyi. this small PR came about while troubleshooting an afternoon project ~9 months ago. I'd like to help others avoid some frustration, but there are limits to the time I can spend on it. If there are some quick changes I can make to get this merged, then please state this clearly. I'm not going to be offended. Likewise if someone would like to take this PR and go further, or do something different.

1. I think I looked at the C headers. These are defined as two decimal numbers, combined with or+shift, which is kind of confusing.

$ grep SQLITE_READONLY /usr/include/sqlite3.h
#define SQLITE_READONLY     8   /* Attempt to write a readonly database */
...
#define SQLITE_READONLY_DIRECTORY      (SQLITE_READONLY | (6<<8))

2. Sure.

As a further idea. I also noticed const char *sqlite3_errstr(int), which seems more future proof than maintaining a duplicate of the error string table. However, I'm personally not keen to wade into JNI again.

[gotson]

I think your PR has value, and i approach it with external eyes, hopefully we can make it beneficial for everyone.

I think the error code displayed will make more sense if it can be looked up using the SQLite webpage.

As a further idea. I also noticed const char *sqlite3_errstr(int), which seems more future proof than maintaining a duplicate of the error string table. However, I'm personally not keen to wade into JNI again.

I think having the enums in Java make sense, as it can be used within the code to perform various conditions and checks. I also agree with you, we shouldn't touch JNI more than necessary 😅

---

I will try to update your PR to display decimal codes, and i will try to include the missing codes too.