search

IreneKnapp / direct-sqlite

MIT License
35 stars 54 forks source link

use extended error codes #87

Closed aryairani closed 2 years ago

aryairani commented 3 years ago

This PR switches from using sqlite3_errcode to sqlite3_extended_errcode, as part of an unsuccessful* attempt to get more info about a SQLITE_IOERR I was getting in my direct-sqlite application, that I thought might be desirable in the main line.

For better or worse, it would require users to reevaluate any pattern matching they were doing on Error values; it may also cause matches for (for example) ErrorIO vs _ to hit the _ case instead of the ErrorIO case, if sqlite returns something more specific.

Also for better or worse, I continued the existing pattern of including the apostrophized word Can't in the error constructors.

Let me know what you think, and if you would like to see some changes.

I haven't seen sqlite actually return an extended error code, and I don't know how to trigger one as a test, so I'm not sure if it's working, but it builds and the existing tests pass, so that's something.

jchia commented 2 years ago

I think it is better if the user can still get the primary result code. With this commit, errcode always produces the extended result code, breaking backward compatibility.

So, instead of changing the existing errcode, a new function extendedErrcode should be implemented that produces the extended result code.

Additionally, perhaps a function toPrimaryError could be implemented to convert an extended result code to the underlying primary result code as described in point 2 here: https://www.sqlite.org/rescode.html

jchia commented 2 years ago

https://github.com/IreneKnapp/direct-sqlite/commit/c1773f863a7938fe44c5cce373504017bd9190e3