Name: rlT66838 Date: 08/18/99


The constructor for GZIPInputStream checks for the gzip magic
number in the first 2 bytes of the stream. Then it throws an
IOException if it doesn't find the right magic number. I assume
the other decompressing streams do the same. This makes it
quite a pain to detect and read compressed data from streams
in a robust way because you can't differentiate a real IO
error from having tried the wrong decompressor. Anyone trying
to read streams with blocks of compressed data is in for
trouble...

Request: Add a java.util.zip.BadMagicNumberException and have
all the decompressors throw that when they don't find their
preferred magic number. This signifies a usage error rather
than an IO error.

Having written and used other data filtering and decomoressing
streams that need to detect thye format, specialized exceptions
seems to be the most robust way to do this so that the streams
are easy to use.

Note: I realize that the message in the IOException mentions
something vaguely meaningful, but one cannot rely on the
content of the message (which could change) when we have such a nice
exception mechanism in place.

The IOException is basically useless because in the absence
of a BadMagicNumberException, one must use the work-around below,
in which case the decompressor should do this stuff for you.
(Review ID: 94081)
======================================================================