Closed V1046RX closed 1 year ago
Yes, this is an expected behaviour. The constructor does not read any content from the stream when initialized. Reading content from zip starts with ZipInputStream.getNextEntry()
. This method can only check if the next 4 bytes in the input stream has the local file header (which is an entry in zip format) signature. Zip4j cannot throw an exception at this stage, because that means, zip4j also has to throw an exception when the complete zip file is read, and the signature is not found anymore in the zip file. So yes, this is an expected behaviour.
Thanks you!
I use ZipInputStream to unpack data in memory, and when I serve it invalid data (in that case it was a short CSV file), to my surprise no exceptions occur. The construtcor ZipInputStream(InputStream, password) returns normally and the first call ZipInputStream.getNextEntry() just returns null (no more entries).
Is this expected behaviour?