try-with-resources and null resource

[Reinier Zwitserloot]

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
>
>