try-with-resources and null resource

[Joe Darcy]

Gernot,

If you can share some statistics of the code base you looked at, lines 
of code, # of finally block, # of finally blocks dealing with nullable, 
resources, other informative things, I would find that to be an 
interesting data point.

-Joe

Gernot Neppert wrote:
> Have you ever browsed a reasonably large codebase and counted the
> occurrences of 'finally' blocks that deal with nullable resources?
> Well, I have, and I found the infamous Class.getResourceAsStream to be
> the _only_ example of such a construct.
> And even that is easy to forego without adding any substantial
> clutter. Simply test the existence of the resource before opening the
> InputStream:
>
> URL resource = getClass().getResource("resourceThatMayOrMayNotExist");
> if(resource != null) {
>    try(InputStream stream = resource.openStream())
>    {
>    ...
>    }
> }
>
> _All other_ uses of try-finally blocks in my code deal with resources
> that are guaranteed to be non-null, because they
> are initialized by 'new' expressions or factory functions:
>
> java.sql.Statements, ResultSets, InputStreams, OutputStreams, Readers,
> Writers, Locks...
>
> In practice, having to deal with null-resources will probably be as
> rare as having to deal with null-iterators in a foreach loop.
>
>
> 2011/1/28 Reinier Zwitserloot <reinier at zwitserloot.com>:
>   
>> I don't understand why one couldn't explain t-w-r by showing "if (resource
>> != null) resource.close();" in the finally block.
>>
>> It is then your opinion that this code is abusing the t-w-r construct,
>> because Class.getResourceAsStream can return null?
>>
>> try (InputStream introTextStream =
>> getClass().getResourceAsStream("intro.txt")) {
>>    ...
>> }
>>
>> If so, we've clearly progressed into the "Everyone has their own 'feeling',
>> none of them agree with each other, and making language decisions based on
>> these feelings is a silly thing to do" phase. Let's check how often the
>> above occurs. I'm betting it'll be "loads of times". Also contrast what
>> you'd have to write if the above is not okay:
>>
>> InputStream introTextStream1 = getClass().getResourceAsStream();
>> if (introTextStream1 != null) {
>>    try (InputStream introTextStream2 = introTextStream1) {
>>        ...
>>    }
>> }
>>
>> I assume I don't have to resort to 'feeling' to claim that the above is just
>> bad.
>>
>>  --Reinier Zwitserloot
>>
>>
>>
>> On Fri, Jan 28, 2011 at 7:38 AM, David Holmes <David.Holmes at oracle.com>wrote:
>>
>>     
>>> Tim Peierls said the following on 01/28/11 00:47:
>>>       
>>>> I don't know about C#, but I like the formulation that can be sloppily
>>>> summarized as "t-w-r calls close on non-null resources".
>>>>         
>>> So to summarize there are three potential candidates for:
>>>
>>> try (Resource r = getResource() {
>>>   // stuff here
>>> }
>>>
>>> I'm ignoring the suppressed exception aspects for simplicity:
>>>
>>> a) Simple transformation into try-finally (current implemented semantics)
>>>
>>>   Resource r = getResource();
>>>   try {
>>>     // stuff here
>>>   }
>>>   finally {
>>>     r.close();
>>>   }
>>>
>>> b) Transformation into try-finally with explicit null-check on entry
>>>
>>>   Resource r = getResource();
>>>   Objects.requireNonNull(r); // heh heh - couldn't resist!
>>>   try {
>>>     // stuff here
>>>   }
>>>   finally {
>>>     r.close();
>>>   }
>>>
>>> c) Simple transformation into try-finally but only close a non-null
>>> resource
>>>
>>>   Resource r = getResource();
>>>   try {
>>>     // stuff here
>>>   }
>>>   finally {
>>>     if (r != null)
>>>       r.close();
>>>   }
>>>
>>>
>>> Option (a) is, perhaps, the most consistent with preserving the
>>> behaviour of current code that would be modified to use the new
>>> construct. This construct will be taught by analogy as it is the only
>>> effective way to explain things "try-with-resources behaves as-if you
>>> had written ....". That said I think existing code would have an
>>> explicit null-check to avoid the try-finally in the null case. And I
>>> think it is potentially risky to execute the try block only to have NPE
>>> thrown later.
>>>
>>> Option (c) seems appealing in some sense because there's no NPE's at all
>>> if you don't use "r", but I think that appeal is superficial. To me the
>>> fundamental question to ask is: what is try-with-resources for? And I
>>> believe the answer to that is to initialize, use and then clean-up an
>>> AutoCloseable object. So to me using try-with-resource on a resource
>>> that might be null is simply a mis-use of try-with-resources: if it can
>>> be null you can't autoclose it, so trying to is a programming error and
>>> programming errors should be detected and reported as early as possible.
>>> So to me option (b) is the preferred semantics for this new construct.
>>>
>>> David Holmes
>>>
>>>
>>>       
>>     
>
>