On Tue, 29 Jun 2021 at 21:24, 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
-0 Too easy to accidentally convert a bug into something that looks like an input error. > (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 +1 I think we should catch known RTEs and wrap with an IEO giving the probable cause. This may take a few iterations to catch them all, but the fuzzer should help here. > (3) catch all RuntimeExceptions, wrap them in an specific unchecked > exception (which one could be discussed later) and throw this one -1 > (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 > "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
