try-with-resources and null resource (original) (raw)

Reinier Zwitserloot reinier at zwitserloot.com
Thu Jan 27 21:50:59 PST 2011

Would it help if I wrote it like this:

try (Transaction t = Transactions.startTransaction()) { // Do all sorts of stuff, but 't' will never be touched. }

I can see that being legal (and useful!). Let's not ditch the null problem by the wayside just because code checkers might flag this as 'no usage of t'. Because the 'expression only' variant of the ARM block has been removed, we WILL see code that wanted an expression without an assignment to a newly declared variable - it'll most likely use a dummy variable declaration.

I have a question, and, presupposing either answer, a followup question:

  1. In the above snippet, is t final?

2 if yes: Well, then, calling a method that returns null, such as for example Class.getResourceAsStream, is going to be an unbelievable pain. As the NPE is then unavoidable, you'd need to assign it to a variable, check that variable, and if that variable is not null, start a try block, which REQUIRES that you create a NEW variable. urghhhhh!!!!!!! What do I name this? out1 and out2? I've got a very big problem with this. even if t is not final, I'd have to create a dummy input stream just to have something to close.

2 if no: What is closed? The object pointed to by variable 't' at the end of the try block / whenever the try block was exited, or, the object pointed at by 't' as it was at the start of the block (i.e. the result of the expression assigned to t).

I guess I'm biased, but I see this as the only sensible way to go:

A. 't' is final, whether you say so or not, and

B. if 't' is null, then no close is called at all. No NPE occurs either.

--Reinier Zwitserloot

On Tue, Jan 25, 2011 at 1:45 PM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> 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? 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

More information about the coin-dev mailing list