propagate errors in Statement initialization

[kujenga]

Reopened against master, replacing #221

Propagates up errors by replacing a try! in the init method for Statements with try and adding the necessary acknowledgements of this throughout the code. See issue #220

[ryanholden8]

Any updates as to whether this will be merged into the repo?
This seems to address #187, which is a similar situation I also ran into.

It seems odd that a library would decide when my app should crash when really the context of the application code is needed to make that determination. (Just my viewpoint though) Thank you!

[kujenga]

@ryanholden8 I just rebased my branch off the tip of master, so if you'd like you're welcome to use it in the interim. I won't be changing anything else on it.

@stephencelis What are your thoughts on pulling this in? Since it does break the API by it's nature, to me it seems the sooner the better.

[stephencelis]

@kujenga Let's figure out the balance here and get something merged 😃

The reason I've been holding off is figuring out this disparity:

1. On the one hand, recovering from errors is important when you're dealing with validation and other recoverable failures.
2. On the other hand, SQL statements that read from the database generally shouldn't fail unless the statement is invalid (e.g., a syntax error, which is usually a developer issue).

Because of this, I'm wondering if we should only promote prepare to be throws, but let the others remain fatal. With this change, developers that need the flexibility of error recovery can use db.prepare, but the rest can generally use the simpler, non-throwing APIs (scalar, pluck, etc.). What do you think?

[kujenga]

@stephencelis Sounds good! I'm in agreement that developer error doesn't necessitate runtime error handling. The scalar method is easy to keep as is, since I converted that one over separately. pluck does call prepare, but I can just add a try! to the guts of that method to provide the proper API. I'll also put a short note in the comments for prepare indicating the reason that it throws an error while the others don't.

Coming right up! 😃

[stephencelis]

Great! Let me know when everything's pushed and I'll take a final look and merge 👍

[kujenga]

@stephencelis Alright! After some liberal rebasing this should be cut down to a more manageable set of changes.

[stephencelis]

Looks good! Thanks for this! 💯