Ah, I see. These exceptions could derive from UncheckedIOException perhaps?
On Sun, 6 Jun 2021 at 15:56, Gilles Sadowski <gillese...@gmail.com> wrote: > > Le dim. 6 juin 2021 à 22:32, Matt Sicker <boa...@gmail.com> a écrit : > > > > Well, if there's a parse error decompressing a file, that makes sense > > as an IOException of some sort. > > The proposal is the change some unspecified RuntimeException > into an unspecified IOException. > My opinion is that a checked exception must restricted to signalling > a problem that can be recovered from. > The situation described here is that the library doesn't even know > what the problem is. > > Gilles > > > > > On Sun, 6 Jun 2021 at 12:01, Gilles Sadowski <gillese...@gmail.com> wrote: > > > > > > Le dim. 6 juin 2021 à 07:51, Stefan Bodewig <bode...@apache.org> a écrit : > > > > > > > > Hi > > > > > > > > I'm thinking about a specific IOException subclass that is thrown when a > > > > RuntimeException "happens" somewhere in the code that parses data in > > > > Zip/SevenZ/TarFile, see > > > > > > I'm afraid I missed part of the story as to what is the original problem. > > > > > > > > > > > https://github.com/apache/commons-compress/compare/catch-RuntimeExceptions > > > > > > > > is this a good idea? > > > > > > IMO, no. > > > Why would one want to create a checked exception from > > > an unchecked one? > > > > > > > Should anything be worded/named differently? > > > > > > IllegalStateException > > > > > > Gilles > > > > > > > > > > > If this seems right I'd add similar code to all > > > > Archive/CompressorInputStream classes as well. > > > > > > > > Personally I would not do the same for the code that writes > > > > archives/compresses streams as in this case the library user is fully > > > > responsible for the input. > > > > > > > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
