Perhaps the key point here is throwing a more specific exception than RuntimeException? Even if it's a subclass of it. Adding the javadocs for which exceptions are allowed to be thrown might be sufficient to cover the DoS attacks.
On Sun, Jun 27, 2021 at 12:05 PM Torsten Curdt <tcu...@vafer.org> wrote: > > > > > > Based on that premise we could also just forget about checked exceptions > > > altogether. > > > > As Gary said (as Joshua Bloch said, as many people said), checked > > exceptions are for recoverable errors. > > > > Maybe it boils down to the definition of "recoverable". > > > > Parsing an archive I personally don't see in that realm. > > > > Even if the archive is just garbage (or any non-supported file format)? > > > > Especially then. Similar to > > > https://docs.oracle.com/javase/7/docs/api/java/net/MalformedURLException.html > > > Comparing all the subclasses of > > https://docs.oracle.com/javase/7/docs/api/java/lang/RuntimeException.html > > vs > > https://docs.oracle.com/javase/7/docs/api/java/io/IOException.html > > I do see this case fit naturally as a subclass of IOException. > > > > > > I'd argue that signaling this problem should be a checked exception. > > > IMO this provides a clearer contract to the user. > > > > It doesn't. The user would have a false sense of security believing so. > > > > I guess I disagree there - and so seem the authors of the JDK. > But that's fine - I just wanted to give my 2 cents :) > I don't have enough stake anymore to keep this discussion going. > > cheers, > Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
