Am 30.06.21 um 14:41 schrieb Gary Gregory:
On Tue, Jun 29, 2021 at 4:24 PM Stefan Bodewig <bode...@apache.org> wrote:Hi I'm sorry, but I'm unable to see what would or would not work for the people who chimed in. Short of calling for a vote, lets try with a poll that could show whether there is some sort of solution that is acceptable to everybody. Please use +1 to mean "I like this option", +0 to mean "the option is OK, but I'd prefer a different one", -0 for "I don't like the option but I can live with it" and -1 for "this option is not acceptable to me. Options raised during the thread: (1) catch all RuntimeExceptions, wrap them in an IOException (possibly a subclass) and throw the IOException-1. There will no end to this and our code will be riddled and cluttered with try-catch clauses.(2) catch only a subset of all RuntimeExceptions, wrap them in an IOException (possibly a subclass) and throw the IOException - allow the remaining RuntimeExceptions to fly through-0. Selective implementation might be OK but I prefer throwing unchecked exceptions for unrecoverable errors like a negative index.(3) catch all RuntimeExceptions, wrap them in an specific unchecked exception (which one could be discussed later) and throw this one-1. That one does not make sense to me.(4) don't catch RuntimeExceptions at all, just document broken archives can cause arbitrary RuntimeExceptions and code that tries to read archives from untrusted sources is expected to deal with them itself.+0. Here what I would prefer to see on our APIs: - Throw IOException where we surface JRE IOException. - Throw NPE where we use methods like Objects.requireNonNull(). - Throw IllegalArgumentException on other garbage API input arguments. - Throw IllegalStateException when the archive is broken.
IIUC, the problem is that [compress] states that it throws an IOException, but in practice can throw arbitrary runtime exceptions as well. So IMHO, it would be a great improvement for the users to come to a definition under which circumstances what outcome is expected.
This will probably require some kind of translation from exceptions thrown during parsing to the exceptions declared by [compress]. How such a translation then looks like, is certainly a matter of taste. As the API currently uses IOExceptions anyway, using sub classes of this type would be fine with me.
In any case, I think we should implement some translation and not let all kinds of unexpected exceptions fall on our users.
Oliver
Gary"Just harden all parsers" is a variation of (4) in my view as I don't believe we would manage to cover all cases no matter how hard and long we try. I hope I didn't overlook any. Thanks Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
