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

Reinier Zwitserloot reinier at zwitserloot.com
Tue Jan 25 00:20:24 PST 2011

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

More information about the coin-dev mailing list