On Fri, 20 Mar 2026 17:55:41 GMT, Alan Bateman <[email protected]> wrote:
> Are you sure a cause of IAE make sense here? Okay for ZipOutputStream as the > argument is a ZipEntry but less obvious here. Oh my. My initial thinking here was that since ZipCoder.getBytes always catches the `CharacterCodingException` and rethrows it wrapped by an IllegalArgumentException, that CCE may provide useful context for the user. However, ZipCoder.getBytes in ZipFS is different from the one in java.util.zip in that it does not use the convenience CharsetEncoder::encode method but implements its own decoding logic and throws IAE directly. I thnk this deserves a separate cleanup to align the ZipFS ZipCoder with the java.util.zip implementation. We don't need two intricately different ways of encoding and reporting errors. Meanwhile, I can drop the cause here as you mention. > Also I assume it will be thrown for both malformed and unmappable cases (need > to check this) Can a String's character sequence be malformed? I assume a CharBuffer can, but the input here is always `CharBuffer.wrap(String)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30319#discussion_r2967998494
