On Thu, 19 Mar 2026 19:34:53 GMT, Eirik Bjørsnøs <[email protected]> wrote:
>>> I could update the PR such that ZipCoder.getBytes throws >>> CharacterCodingException directly instead of rethrowing IAE. Would you like >>> me to go down that road? >> >> On the other hand, ZipCoder.toString also wraps CharacterCodingException in >> IllegalArgumentException. This is what causes ZipCoder.checkedHash to >> awkwardly declare `throws Exception` because the base class throws >> CharacterCodingException while the UTF8ZipCoder override of this method >> throws IllegalArgumentException via toString. >> >> Perhaps it would be better to leave this as-is in this PR and do a follow-up >> PR where we investigate if getBytes, toString and checkedHash can all be >> consolidated to just throw CharacterCodingException? >> >> WDYT? > >> Perhaps it would be better to leave this as-is in this PR and do a follow-up >> PR where we investigate if getBytes, toString and checkedHash can all be >> consolidated to just throw CharacterCodingException? > > A quick prototype to declare toString (with overloads), getBytes, and > checkedHash as `throws CharacterCodingException` revealed no showstoppers. > For convenience we may want to introduce a variant of toString which throws > IEA, for use by clients who have already validated the encoded string though > checkHash or similar. But those changes clutter the intent of this PR, so > should perhaps be taken care of separately? ZipOutputStream::setComment and other setXXf methods throw IllegalArgumentException vs ZipException per the javadocs so we have a difference to deal as part of how we address the issue We probably want wrapper method (or overloaded) for at least ZipOutputStream so we can avoid multiple try/catch Also, I am wondering if we should set the cause to an IAE as the cause to the ZipException. Not sure there is a huge win valuewise, but thought I would through it out for discussion ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30319#discussion_r2962580680
