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. 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
