Sure, the whole point is that this is not something you are going to use
given the choice to use other methods on the template, but mainly when
you need to wrap existing code which throws SQLException. In the
particular case I needed yesterday, I actually also needed to pass a
connection to the other code. There could be a variant which gets a
connection for you, for this sort of case. I don't like the
possibility that people will now use this sort of method to write
old-style code which doesn't clean up resources properly, as you
mention, but on the other hand, if we document it well it will hopefully
be helpful for these kinds of situations. In this case, I ended up
having to manage the connection myself, and had to wrap to catch SQL
exceptions, etc....
Colin
Thomas Risberg wrote:
> The only drawback that I can think of is that now you are responsible
> for closing any statements/resultsets that you open - you need to
> provide a try/finally block within the callback to properly close them
> in case of an exception being thrown. As long as we document this, we
> should be OK.
>
> Thomas
>
> Colin Sampaleanu wrote:
>
>> Does anybody think it doesn't make sense to add a
>> JdbcOperationsCallback interface, similar to some of the other
>> callbacks, which can be used via a new
>> jdbcTemplate.execute(JdbcOperationsCallback)
>> method? This could be used to wrap arbitrary code which throws SQL
>> exceptions, so that they are properly mapped. I've had a need for
>> something like this a few times...
>
|
