Question of the Day - Responses

Re: How do I get a stack trace in a String?

Ever — Wed, 03 Dec 2008 19:32:17 GMT

Hi there,

Just a minor correction. "sw" needs to be passed to the PrintWriter constructor.

Thanks for putting up this blog!

Re: Horrible JDBC Code and What's Wrong With It

Erkki Lindpere — Fri, 14 Nov 2008 01:21:49 GMT

I can agree with not wanting to introduce dependencies, but this is the way to do non-ORM database access in Java at the moment. It's not so ok to write twenty lines of raw JDBC, if you can do it in a couple of lines with JdbcTemplate.

Even if you don't want to use Spring (I can definitely see why one wouldn't), you can write your own JdbcTemplate analogue -- it may not be totally trivial, but it's not very complicated either and one that handles 80% of the functionality can probably be done in 200 lines of code (wild guess). Maybe you could even copy some of the code from Spring, I think the license allows that.

Re: Horrible JDBC Code and What's Wrong With It

Keccs — Thu, 13 Nov 2008 19:47:06 GMT

Also, storing pin codes in plaintext is not a good idea.

Re: Horrible JDBC Code and What's Wrong With It

Anonymous — Thu, 13 Nov 2008 15:31:01 GMT

JdbcTemplate, JdbcTemplate, JdbcTemplate

Re: Horrible JDBC Code and What's Wrong With It

Joseph B. Ottinger — Thu, 13 Nov 2008 15:14:58 GMT

Not terrible advice, but...

Most of your points go straight at the problem definition, and not the code. The original code made obvious an assumption that all customer numbers were, well, numbers. Using a string when a number is mandated is pointless.

The situations where exceptions exist for failure are also problem-domain related; the original code returned true or false, where false was apparently a catchall for "all failure conditions, including invalid authentication."

I'd agree with you for the most part: throw an unchecked exception in the case of a service failure, and return a "no user" value for a non-matching condition. <code>boolean</code> is a little too simple for this.

Re: Horrible JDBC Code and What's Wrong With It

Joseph B. Ottinger — Thu, 13 Nov 2008 15:10:16 GMT

@RJones: It *is* example code, and isn't meant to be the end-all of login authentication. As far as not catching exceptions other than SQLException... are you expecting them to be thrown? I'm not. It'd be silly of me to try to catch exceptions that the type system refuses to inform me of - because the exception system will tell me if an exception type will be thrown that requires my attention. As far as runtime exceptions are concerned: the finally block will, in fact, clean up the resources as soon as the JVM allows it (if the JVM allows it.) Setting the resources to null - when they're local references - may make you feel better, but it really does nothing to hint to the GC to "collect these faster."

Re: Horrible JDBC Code and What's Wrong With It

Anonymous — Thu, 13 Nov 2008 14:43:32 GMT

I wold say do not concatenate the prepared statement string - immutable strings. That is also a was of cpu effort.

I'd say not all companies have numbers for customer id, therefore keeping it as a String still forces you to check it's not null/empty so that you don't waste a database connection. This could be true of the password as well, but we could never know what types are in the database anyways. Unless of course, a prepared statement was used.

I'd say the cardinal sin here is not using a PreparedStatement in order to spare the database and help with XSS or Sql injection.

Then the nested rs.next() is pretty funny really. Never seen it before.

Then the method should throw a runtime AuthenticationException, and a ServiceTemporarilyUnavailableException (after logging underlying exception) rather than a boolean value.

etc.

Re: Horrible JDBC Code and What's Wrong With It

RJones — Thu, 13 Nov 2008 13:54:16 GMT

Even if your exception handling is not complete your code is flawed.

You fail to catch any Exceptions outside SQLException. There should always be at least (and this includes examples) a standard Exception catch.

For example you may wish to catch runtime exceptions. If you failed to do this you could fail to close ps and rs and leave them unclosed.

Also I would null them as well after closing to let the GC know to collect them asap.

And there are probably many others but I cannot be bothered right now.