try-with-resources and null resource

[Reinier Zwitserloot]

This reasoning (that the NPE on a line with just } on it is from the close()
call you didn't have to write yourself) presupposes that everyone looking at
an ARM block simply sees some syntactic sugar.

This is true _now_. But will it still hold in 5 years? I surely hope not.
When I'm looking at a foreach loop today, the notion "Iterator" doesn't even
register in my mind anymore. Sure, you have to know how it works in plenty
of circumstances - I'm not trying to argue that we'll eventually get to a
place where a java developer can call himself that without even knowing
about close(); methods. For example, if I attempt to foreach over a null
ref, I interpret the NPE that results as caused by the fact that I tried to
iterate over a null ref. I don't interpret it as the more technically
correct: the .iterator() call that was generated failed, as it was called on
a null ref.

I've got a slight preference of simply not calling close() at all if the
to-be-closed resource is a null pointer, but generating an exception that
explicitly states the problem works too.

 --Reinier Zwitserloot



On Mon, Jan 24, 2011 at 8:00 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> On 1/22/2011 5:09 AM, Rémi Forax wrote:
> > On 01/21/2011 08:38 PM, Joe Darcy wrote:
> >> Rémi Forax wrote:
> >>> I think try-with-resources should do a null check before entering in
> >>> the try block.
> >>>
> >>> 4. try(AutoCloseable c = null) {
> >>> 5.     // nothing
> >>> 6. }
> >>>
> >>> $ java TryWithresourceNPE
> >>> Exception in thread "main" java.lang.NullPointerException
> >>>      at TryWithresourceNPE.main(TryWithresourceNPE.java:6)
> >>>
> >>> I got a NPE from the ends of the try block, I think it will be
> >>> better to detect the case
> >>> before entering in the try block like foreach or switch does.
> >>>
> >>> And with this code:
> >>>
> >>> 5. try(InputStream i = null) {
> >>> 6.       i.available();
> >>> 7. }
> >>>
> >>> I got the exception below which is not understandable if you don't know
> >>> how try-with-resources is translated.
> >>>
> >>> $ java TryWithresourceNPE
> >>> Exception in thread "main" java.lang.NullPointerException
> >>>      at TryWithresourceNPE.main(TryWithresourceNPE.java:6)
> >>>      Suppressed: java.lang.NullPointerException
> >>>          at TryWithresourceNPE.main(TryWithresourceNPE.java:7)
> >>
> >> I'm not too concerned about that stacktrace since the primary
> >> exception points to the right location.
> >
> > But the suppressed exception occurs in a generated code that the user
> > don't write.
>
> But that is the whole point of try-with-resources, to allow users to not
> have to write the messy and error-prone clean-up code.
>
> > I don't like the idea that a user mistake blow up in a generated code,
> > try-with-resources should protect itself.
>
> I think this stack trace can easily be explained to programmers by
> saying "the suppressed exception comes from the close call you did have
> to write yourself."
>
> -Joe
>
>
>