On Fri, 20 Mar 2026 20:57:44 GMT, Eirik Bjørsnøs <[email protected]> wrote:
>> Yes I see what you are saying and I agree with the validation happening
>> earlier. I just want to avoid multiple try blocks for this. Could do
>> something similar to ZipFile::initCen which keeps it tidier
>
>> Yes I see what you are saying and I agree with the validation happening
>> earlier. I just want to avoid multiple try blocks for this. Could do
>> something similar to ZipFile::initCen which keeps it tidier
>
> Sorry for being slow, I finally think I understand: You want to coalesce the
> try/catch for validating name and comment because you find the repeated try /
> catch noisy or untidy.
>
> ZipFile::initCen is somewhat different in that it processes a pre-existing
> ZIP which is either corrupt or opened using an unexpected Charset. So the
> source of the problem is more far removed.
>
> In the ZipOutputStream producer case, where a user is supplying the name or
> comment directly, I think knowing whether it was the name or the comment that
> was incorrect is useful informartion for the user.
>
> How about we extract the try / catch into a helper / checker method, such
> that the validation looks like this:
>
>
> // Verify that entry name and comment can be encoded
> checkEncodable(e.name, "unmappable character in ZIP entry name");
> if (e.comment != null) {
> checkEncodable(e.comment, "unmappable character in ZIP entry
> comment");
> }
> ```
>
> where checkEncodable is:
>
>
> // Throws ZipException if the given string cannot be encoded
> private void checkEncodable(String str, String msg) throws ZipException {
> try {
> zc.getBytes(str);
> } catch (IllegalArgumentException ex) {
> throw (ZipException) new ZipException(msg).initCause(ex);
> }
> }
Yes that is basically what I am suggesting as it reduces the boilerplate
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30319#discussion_r2967976553
