The WebSphere Adapter for JDBC has some weird behavior if are querying a table. Should your select statement return zero records, the adapter will write a RecordNotFound exception to the System.out log. I can then catch the error in my code and continue along my merry way. Doesn’t sound harmful does it?

This about this from the system support perspective. You now have an exception written to system out that is completely ignorable, but may occur hundreds or thousands of times an hour. They’re benign, but what happens when a legitimate exception occurs on my server? I have to look through tons of superfluous exceptions. It’s highly likely that I’ll miss the source of the real error, increasing resolution time. Remember, that I’m already catching my exception in my own code. It’s the logic inside the adapter that is spewing stack trace to system.out.

Why does the adapter immediately interpret RecordNotFound as an exception worthy of writing to the log? It’s perfectly acceptable from a business perspective to execute a select statement and expect zero rows. There is no option to turn this off or mark the query as ‘null ok’.

I also know that the adapter has been doing this for years and IBM apparently refuses to fix it. It’s working “As Designed”. “As Designed” usually translates to “Yes you are right, but we’re not going to fix it”.

What I don’t understand is why there is such a fight to have this resolved. It seems like a trivial low-impact change to make that could be included in any of the fixpacks that have been released over the last two years. The code change should be nothing more than removing the ‘e.printStackTrace() ;’ from the code. If they want to log the exception, then use WebSphere tracing like they should so that my client can turn it off.

Now, where does that leave my client? They’re considering removing all uses of the adapter from their solutions and coding the JDBC calls themselves. All because IBM won’t remove a single printStackTrace.