search

IreneKnapp / direct-sqlite

MIT License
35 stars 54 forks source link

Fix error code mixup between ErrorCorrupt and ErrorNotFound #6

Closed joeyadams closed 12 years ago

joeyadams commented 12 years ago

The persistent-sqlite3 package copied this mistake. To avoid having to maintain this list in two places, I wrote a package called "sqlite3-error-codes", which contains nothing but Error, encodeError, and decodeError, plus documentation copied from SQLite3's documentation. However, I haven't released it yet. Do you mind if I release it as public domain? More precisely, I'm asking for permission to use the data constructor names like ErrorCan'tOpen.

joeyadams commented 12 years ago

To avoid having to maintain this list in two places, I wrote a package called "sqlite3-error-codes", which contains nothing but Error, encodeError, and decodeError, plus documentation copied from SQLite3's documentation. However, I haven't released it yet. Do you mind if I release it as public domain? More precisely, I'm asking for permission to use the data constructor names like ErrorCan'tOpen.

On second thought, I want to get persistent-sqlite to depend on direct-sqlite (see issue #92 for persistent-sqlite). Making a package just for the error codes risks even more fragmentation.

IreneKnapp commented 12 years ago

I'm happy to merge this. I take it you only just learned that the package is still maintained now that I have it on github instead of my personal website? :) Well, cool!

IreneKnapp commented 12 years ago

Also and by the way, I would of course have no problem with you using my error code names. That's what open-source means! But I was chewing on how to tactfully point out the fragmentation issue; I'm glad you've thought better of it.

joeyadams commented 12 years ago

I'm happy to merge this. I take it you only just learned that the package is still maintained now that I have it on github instead of my personal website? :) Well, cool!

Well, I heard about it before (I think you mentioned it in IRC). But sqlite-simple was released recently, and it uses direct-sqlite. In any case, putting it on Github makes it easier for me (at least) to contribute. Thanks!

Just a heads up: I'm working on a wide-spread, but non-breaking, change right now: use phantom types for pointers (e.g. Ptr CDatabase instead of Ptr ()) to improve type safety internally. After that, I plan to make the library throw its own exception type, which is a breaking change (since catching IOError will no longer catch database exceptions).

IreneKnapp commented 12 years ago

Well, thanks for the heads up. :) The phantom types make a lot of sense. Using its own exception type I'm less sure about, but it's probably a good idea.

nurpax commented 12 years ago

FWIW, I would support @joeyadams 's idea of making direct-sqlite throw its own exceptions too.