try-with-resources and null resource

[Stephen Colebourne]

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.

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