try-with-resources and null resource (original) (raw)
Stephen Colebourne scolebourne at joda.org
Fri Jan 28 02:39:26 PST 2011
- Previous message: try-with-resources and null resource
- Next message: try-with-resources and null resource
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 _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
- Previous message: try-with-resources and null resource
- Next message: try-with-resources and null resource
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]