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
