try-with-resources and null resource
jesper.oqvist at cs.lth.se
Fri Jan 28 07:50:42 PST 2011
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
> 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.
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
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.
> 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.
> private IdentifierSearch _securityKeys;
> * The security name, wildcards allowed, null to not match on name.
> 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
> 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.
More information about the coin-dev