try-with-resources and null resource (original) (raw)
Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Jan 25 04:45:58 PST 2011
- Previous message: try-with-resources and null resource
- Next message: try-with-resources and null resource
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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? 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).
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
- Previous message: try-with-resources and null resource
- Next message: try-with-resources and null resource
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]