try-with-resources and null resource

[Rémi Forax]

On 01/25/2011 01:45 PM, Maurizio Cimadamore wrote:
>
>>> Javac will warn you about this situation.
>> Why ? It's a fair code.
>> And adding a new warning has a cost. If there is too much
>> not-that-useful warnings,
>> users will don't care about them or worst deactivate them all.
>> If there is a warning, what is the way to fix it ? Introduce a
>> t.getClass() ?
>>
>> try(Transaction t = Transactions.getTransaction()) {
>>      t.getClass(); // remove that stupid javac warning
>> }
>>
>> That's exactly what I'm proposing :)
>>
> Adding a warning has a cost, right - but this particular kind of 
> warning can be activated on-demand using -Xlint:twr (and it's disabled 
> by default). When do you say that the above code is fair, do you mean 
> that it is a legal Java program or that it can actually achieve 
> something good? 

Both.

> I think the only case in which the above program is interesting is if 
> Transaction.getTransactions() has some hidden side-effects. Otherwise 
> the whole thing looks like a no-op (modulo Exceptions being thrown at 
> runtime).

Usually the transaction is attached to the current thread using a 
thread-local value and
the persistent manager can query it when necessary,
by example, javax.persistentence.EntityTransaction works like that.

>
> We currently have some similar warnings in the following case:
>
> switch (xyz) {
> case 1: //do something here then fall-thorugh
> case 2: //do another thing
> }
>
>
> Which, to some extent, is another fair program... but I think that 
> both programs (the one with unused twr variable and the one with 
> fall-through) are somewhat suspicious enough to merit a 'style' warning.
>
> Moreover, this kind of warnings can be suppressed with the usual 
> scheme - just add @SuppressWarnings("twr") to the enclosing method 
> decl, and the warning will go away.
>
> Maurizio

Rémi