I vote for the subclass of IOException - if you care about handling broken 
archives you would catch it, if you don’t care you have to handle IO problems 
anyway.

Gruß
Bernd

--
https://Bernd.eckenfels.net
________________________________
From: Gilles Sadowski <gillese...@gmail.com>
Sent: Wednesday, June 30, 2021 12:33:16 AM
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [compress] [Poll] Dealing with uncaught RuntimeExceptions

Le mar. 29 juin 2021 à 22:24, Stefan Bodewig <bode...@apache.org> a écrit :
>
> 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
[As a matter of principle, we should not force users to handle checked
exceptions; but, as said previously, it can be mandated by design, .e.g.
the (strange) promise that no other exception can arise from calling the
library.]

>
> (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
[Same reason (it's a variant of the above).]
But how will you choose which should be caught or allowed to fly?

>
> (3) catch all RuntimeExceptions, wrap them in an specific unchecked
>     exception (which one could be discussed later) and throw this one

+0
 A sane solution that can satisfy two categories of users:
  (A) those who want to easily catch everything that comes out, and
  (B) those who want to make sure that no error can go unnoticed.

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

+1

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

Reply via email to