RE: Patch: ZipFile.getInputStream shouldn't throw NoSuchElement.

["David Holmes" <dholmes at dltech dot com dot au>]

Anthony Green writes:
> I think that throwing NoSuchElement is clearly wrong from the
> NoSuchElement documentation, and would be surprising given the
> getInputStream documentation.

I agree.

> FileNotFoundException would also be a
> surprising result, and wrong since we're not opening a file (as per the
> FileNotFoundException documentation).

Ok - the docs for FileNotFoundException are a bit too specific, and based on
that it is not a "good fit". But based on those docs only the three classes
listed are allowed to throw this exception and that is clearly wrong. Such
exception classes should document the basic meaning of the exception (a file
was not found) and then give examples of specific cases known to throw the
exception. But that's beside the point.

> ZipException is reserved for ZIP format errors.

The javadocs in 1.4.2 state:

"Signals that a Zip exception of some sort has occurred"

I think asking a zip file for a stream to a zip entry that is not in the zip
file fits in that definition quite well and is perfectly reasonably.

> Applications are depending on this behaviour, and it's an intuitive
> enough result that I think we should just make this change.

Hmmm An intuitive answer to an ill-formed question - I'm not sure there is
such a beast.

This is an error situation that can arise in two ways as far as I can see:

1. You pass an arbitrary ZipEntry to someZipFile.getInputStream

   This is clearly a silly thing to. Trying to be reasonable in the face
   of this just doesn't come in to it.

2. You got the ZipEntry from the zip file but when you ask for the input
stream the zip file can't find that entry.

  This clearly is an error in the zip file, hence ZipException is quite
  appropriate to throw.

I don't see how applications are depending on null being returned in this
case. At best finding null would result in an application specific exception
being thrown (rather than ZipException), at worst applications won't check
the result and you'll get a NullPointerException.

Someone should a have filed a JDK bug on this a long time ago, so that
either the code was fixed or the docs were fixed.

Anyway, do as you will, there's nothing more I can say.

David Holmes