try-with-resources and null resource (original) (raw)

Reinier Zwitserloot reinier at zwitserloot.com
Mon Jan 31 19:24:11 PST 2011

Jesper,

how?

If I call getResourceAsStream, and I NEVER reference the resulting inputstream, that'd be very weird code. I can imagine, though, that I am going to nullcheck this resource and take some alternative action if the resource is missing. Or I presuppose it has to be there, and I'll get an NPE anyway (though at a much nicer point than the close brace!) - The point is, with 'nulls aren't closed', this is simple to write. With 'nulls cause NPEs', this is a major pain to write, requiring 2 variables, both of which take up a name. Having to come up with frivolous names does not feel like good design to me.

You keep saying 'silently ignore', but this cannot happen. You open a resource, you'll read from it. The corner case of opening a 'resource' without the need to actually read from it, for example as some sort of transaction or custom implementation that feels a lot like java's synchronized () {} block, well, those blocks are yet to be built, and the library designers can keep in mind that returning nulls out of the 'createTransaction' method is a very bad idea.

As Stephen said, just because gRAS is the only one a casual inspection can find in java.*, doesn't mean it'll be the only one in the greater java ecosystem. Also, personally I find gRAS enough of a use case even if it IS the only one.

Note that 'fixing' it by writing your own static wrapper sounds like a horrible idea (note how we're now attempting to fix the mistake of Collections.sort and friends by introducing defender methods), and we can't use the defender method JSR to fix this, as Class is not an interface. Certainly adding a new method to j.l.Class to replace gRAS is also not a good option, and, finally, FileNotFoundException is a bad name. It would have to be ResourceNotFoundException - thus adding a new class to java.lang, which is also a very bad idea. (Or, add it to java.io, which is still not entirely risk-free, and weird, as a java.lang class will be the only code that ever throws a java.io exception).

--Reinier Zwitserloot

On Fri, Jan 28, 2011 at 10:55 AM, Jesper Öqvist <jesper.oqvist at cs.lth.se>wrote:

Hi Reinier,

On 2011-01-28 06:50, Reinier Zwitserloot wrote: > I have a question, and, presupposing either answer, a followup question: > > 1. In the above snippet, is t final? Yes > 2 if yes: Well, then, calling a method that returns null, such as for > example Class.getResourceAsStream, is going to be an unbelievable pain. As > the NPE is then unavoidable, you'd need to assign it to a variable, check > that variable, and if that variable is not null, start a try block, which > REQUIRES that you create a NEW variable. urghhhhh!!!!!!! What do I name > this? out1 and out2? I've got a very big problem with this. even if t is not > final, I'd have to create a dummy input stream just to have something to > close. If Class.getResourceAsStream returns null, it means the resource could not be found. In most cases you want to handle this scenario explicitly instead of skipping the resource entirely. If the try with resources-statement would silently ignore that the resource was null, then possible errors might go unnoticed by the programmer. 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". Jesper

More information about the coin-dev mailing list