try-with-resources and null resource

[Reinier Zwitserloot]

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
>
>