Le mer. 30 juin 2021 à 02:32, Bernd Eckenfels a écrit :
>
> I vote for the subclass of IOException - if you care about handling broken
> archives you would catch it,
Yes, but you can catch a runtime exception all the same.
An application that doesn't want to terminate abruptly must catch
all exc
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
Sent: Wednesday, June 30, 2021 12:33
Le mar. 29 juin 2021 à 22:24, Stefan Bodewig 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 everybo
> (1) catch all RuntimeExceptions, wrap them in an IOException (possibly a
> subclass) and throw the IOException
>
+0
> (2) catch only a subset of all RuntimeExceptions, wrap them in an
> IOException (possibly a subclass) and throw the IOException - allow
> the remaining RuntimeExce
On Tue, 29 Jun 2021 at 21:24, Stefan Bodewig 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.
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 opti
On 2021-06-29, Miguel Munoz wrote:
> Catching all RuntimeExceptions and wrapping them in an IOException
> looks like the cleanest solution. RuntimeExceptions usually mean bugs,
> so if the archive code is throwing them due to a corrupted archive, it
> makes sense to wrap it in a checked exception.
> Recovery may not be possible for a single archive, but the caller may
> want to process multiple archives.
> (Or potentially try again, if the error was caused by a transient error
> [1])
>
> So ideally Compress will return a CE for parsing errors, and that CE
> should give some context to the er
On Tue, 29 Jun 2021 at 12:16, Gary Gregory wrote:
>
> The best reason to create a new IO exception is if you are going to catch
> it instead of the original and recover differently. I don't think that's
> the case here, there is no "recovery" possible on a corrupted archive. For
> my money, the ex
The best reason to create a new IO exception is if you are going to catch
it instead of the original and recover differently. I don't think that's
the case here, there is no "recovery" possible on a corrupted archive. For
my money, the exception can remain unchecked as it is unrealistic that
recove
Catching all RuntimeExceptions and wrapping them in an IOException looks like
the cleanest solution. RuntimeExceptions usually mean bugs, so if the archive
code is throwing them due to a corrupted archive, it makes sense to wrap it in
a checked exception. I would like to suggest creating a new c
11 matches
Mail list logo
