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 class looking
something like this:
public class CorruptedArchiveException extends IOException { }
In fact, since we will only be generating them in response to a
RuntimeException, we may want to make sure all constructors require an
RuntimeException as a parameter, to guarantee that we wrap the original
unchecked exception.
— Miguel Muñoz
———
4210 Via Arbolada #226Los Angeles, CA 90042
323-225-7285
–
The Sun, with all those planets going around it and dependent on it, can still
ripen a vine of grapes like it has nothing else to do in the world.
— Galileo
On Monday, June 28, 2021, 06:52:02 AM PDT, Gilles Sadowski
<gillese...@gmail.com> wrote:
Le lun. 28 juin 2021 à 08:52, Stefan Bodewig <bode...@apache.org> a écrit :
>
> On 2021-06-27, Gilles Sadowski wrote:
>
> > Le dim. 27 juin 2021 à 21:15, Stefan Bodewig <bode...@apache.org> a écrit :
>
> >> As I said, we can as well document that each method could throw
> >> arbitrary RuntimeExceptions, but I don't believe we can list the kinds
> >> of RuntimeExceptions exhaustively
>
> > Why not?
> > Listing all runtime exceptions is considered part of good
> > documentation.
>
> Because we do not know which RuntimeExceptions may be caused by an
> invalid archive.
>
> Most of the RuntimeException happen because our parsers believe in a
> world where every archive is valid. For example we may read a few bytes
> that are the size of an array and then create the array without checking
> whether the size is negative and a NegativeArraySizeException occurs.
>
> As we haven't considered the case of a negative size in code, we also do
> not know this exception could be thrown. If we had considered the case
> of negative sizes, the parser could have avoided the exception
> alltogether. This is what I meant with
>
> >> - if we knew which exceptions can be thrown, then we could as well
> >> check the error conditions ourselves beforehand.
>
> Our parsers could of course be hardened, but this is pretty difficult to
> do years after they've been written and would certainly miss a few
> corner cases anyway.
Thank you for the example. I now understand that the aim is not
to increase the number of precondition checks but only to ensure
that a single exception can escape from calls with "undefined"
behaviour whenever some precondition is not fulfilled.
IIUC, the situation where the library assumes some precondition
but does not check it, and continues its operations until something
unexpected occurs, would be described by "IllegalStateException".
[A very much "non-recoverable" state, as the library doesn't know
the root cause (which may be a long way from where the symptom
appeared).]
In principle, it looks interesting information for users to be able to
distinguish between a known failure (i.e. the library knows the root
cause) and an unknown failure (?).
> And then there is a certain category of exceptions thrown by Java
> classlib methods we invoke. We've just added a catch block around
> java.util.zip.ZipEntry#setExtra because certain invalid archives cause a
> RuntimeException there - and if I remember correctly a RuntimeException
> the method's javadoc doesn't list.
It shows that similar JDK functionality can indeed throw a runtime
exception when it gets unexpected garbage. What is their rationale
for choosing this or "IOException" (I have no idea)?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
