try-with-resources and null resource

[Jesper Öqvist]

Stephen Colebourne wrote:
> On 28 January 2011 09:55, Jesper Öqvist <jesper.oqvist at cs.lth.se> wrote:
>   
>> I believe that suppressing NPEs just serves to obscure actual problems
>> in the handling of your resources.
>>
>> This whole discussion highlights why programming with null is a bad
>> idea, but if we must use null then there should be exceptions whenever
>> we try to use null. Java is already a bit confused on this point - in
>> some cases null means  "nothing" while in other cases it means
>> "invalid/error".
>>     
>
> Sadly, this list, Sun and Oracle continue to have trouble with null.
> As Brian Goetz said recently IIRC, the null genie is already out of
> the bottle.
>
> Null is used everywhere is real code (ie. code written by the 99.9% of
> people *not* on this list). I use null all the time, which frequently
> gets me criticised here.
>   
Stephen,

Null is of course not such a Bad Thing if you are consistent about what 
using null actually means.

Null commonly seems to mean "nothing" as in methods which can not 
complete some task and return a usable object will often return null to 
indicate that the result is "empty" in some sense (cf Map.get(key) )

On the other hand null is also an "error" in that it will cause NPEs if 
you try to use a null reference.

My interpretation of null is the "error" meaning, and as such I think a 
try-with-resource statement should throw an NPE instead of silently 
ignoring null.

I tried to express this opinion in my previous message but perhaps I was 
a bit too brief.

Where the NPE should be thrown is another question.

Jesper
> The reality is that null has valid meaning is enterprise coding, with
> JavaBeans being the key part. Here is a classic use case:
>
>   /**
>    * The set of security object identifiers, null to not limit by
> security object identifiers.
>    * Note that an empty set will return no securities.
>    */
>   @PropertyDefinition(set = "manual")
>   private List<ObjectIdentifier> _securityIds;
>   /**
>    * The security keys to match, null to not match on security keys.
>    */
>   @PropertyDefinition
>   private IdentifierSearch _securityKeys;
>   /**
>    * The security name, wildcards allowed, null to not match on name.
>    */
>   @PropertyDefinition
>   private String _name;
>
> Nulls are everywhere, and using null as a return type to indicate that
> something isn't present (like a resource) is very widespread.
>
> Now, many here take the view that using null in that way is a Bad
> Thing and should be stamped out. I'm here to tell you that its not
> going to be stamped out as (a) its use is too widespread and (b) its
> often better than the alternative.
>
> Language changes should be enhacing the language to help manage it
> better (cf the nul-handlinng operators I proposed for Coin, and
> Fantom's nullable types). Go to a conference with real developers, and
> you'll find they are crying out for this. I'm sorry, but it drives me
> mad to see null-purity being foisted on the desires of real
> developers.
>
> So, while getResourceAsStream() might be the only case in the JDK, and
> it might be the only case in some of this mailing lists participants,
> it most certainly isn't the only case overall. The alternative code to
> write when the resource is null, is dreadful, and bug-prone.
>
> Of David's three semantics, (c) is what users want, (b) is expainable
> but undesirable, and (a) is just enexpected and wrong.
>
> Stephen
>
>