You are viewing an old revision of this post, from February 26, 2006 @ 17:43:00. See below for differences between this version and the current revision.
Hey, this JDBC stuff really works!
I could really do without checked exceptions, though: every single time I call a JDBC function, I have to add four lines of try/catch wrapper code, because an SQLException could be thrown at any time. Sigh. And I can’t think of a good way to avoid that, given that I want to wrap the JDBC code in an abstraction layer as quickly as possible, so I need to translate exception types; occasionally, a try block covers multiple statements, but not very often.
I’m still not writing all the data out – for now, all I’m writing is the table mapping entity numbers to entity types. I was going to first write the code (using my abstraction layer, not the real JDBC stuff) that would add all the data for each entity to the appropriate table, but I realized that, if I started there, then it would be too long before I could verify my work via acceptance tests. (And, in particular, I’d be able to put off using JDBC for too long.) So I changed my focus to getting to JDBC calls verified with acceptance tests as quickly as possible; that was a good move, and I’m honestly amazed at how easy it was to get a passing acceptance test. It should be smooth sailing from here on out – the rest of the code shouldn’t involve any new tricks and will be easily unit-testable. (Though I will throw in acceptance tests as well, of course, being a good boy.)
Post Revisions:
- May 5, 2010 @ 20:24:25 [Current Revision] by David Carlton
- February 26, 2006 @ 17:43:00 by David Carlton
Changes:
There are no differences between the February 26, 2006 @ 17:43:00 revision and the current revision. (Maybe only post meta information was changed.)
Posts
Grrr… API’s that throw exceptions. There ought to be an automated way to deal with this kind of mis-feature.
3/3/2006 @ 9:21 am
Throwing exceptions is good – the database connection could go south at any time, after all, and I’d rather have exceptions than return codes. And I would even be forced to concede that, if we’re going to make a checked exception / unchecked exception distinction, that the exceptions should be checked. I just don’t believe in the whole checked exception thing in the first place. (Though it is admittedly less of a misfeature in Java than in C++.)
I’m of two minds as to what I should do in my own code here – when I translate these exceptions into my own exception type, should I make my own exceptions be checked or unchecked? In the past, I’ve gone with the former, because in general I like to write code that’s idiomatic in the language that I’m using. But if I were to do that in this case, I would have to stick a throw spec on tons and tons of methods; this would in no way improve clarity, and given that I’m only planning to catch exceptions at the top level, it wouldn’t improve safety either.
3/3/2006 @ 9:26 am