Le jeu. 1 juil. 2021 à 11:31, Torsten Curdt <tcu...@vafer.org> a écrit : > > > I'm not sure what you refer to exactly, > > > The various links from > > https://docs.oracle.com/javase/7/docs/api/java/io/IOException.html > > or even > > https://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html > > > > but I noted already that not all > > references are equal, especially if you quote design decisions that date > > back from the early Java days (when every textbook touted checked > > exceptions as _the_ solution to robust programming). > > > > So IllegalArgumentException is not from the early Java days?
It is, so what? It's the exception I use 99% of the time (to signal failed precondition)? It's a runtime exception. My point, all along, is that I have a hard time finding a single proper use of checked exceptions (in libraries such as we deal with here), not counting the cases where one was right, at the time, to mimic JDK usage of checked exceptions. I said from the outset of this discussion that if the purpose is to stay true to the initial design decisions, it may be OK to continue with "IOException". As you indicate below, the currently advertised way to handle recovery is with "Optional". > > > ... > > Ask yourself how the programmer will handle the exception ? If the > > programmer > > can’t do better than e.printStackTrace() or throw new AssertionError(), > > then, an > > unchecked exception is called for. > > > > And I guess that's the point - the programmer can do better. > > There should be a difference of action when the code knows the archive is > broken in contrast there being a problem with the code reading it (for > whatever reason). The difference does not entail the checked vs unchecked selection. > > One is "sorry, this is an invalid archive" while the other is "something > went wrong reading the archive - printStackTrace". If that distinction is > not important to you - so be it. To me that's a big difference. Never said such a thing. > The "sorry, this is an invalid archive" is what makes the situation > for me "recoverable". This is plain wrong: From the POV of (any) library, failure to satisfy a precondition is not recoverable, by definition of "precondition". [Here there is often no simple check, but that does not change the principle.] I don't see why the library should be expected to explain in details why an archive is corrupt; it is good enough that it can detect it, and very good if it can protect the caller from himself (by throwing *any* exception rather than crashing the JVM or giving root access. ;-) > For me "recoverable" does not mean running the same code with the same > input twice and expecting a different result. In effect this is exactly what one does in the only case I know of, where a checked exception may be appropriate (as per the two conditions mentioned earlier), that is when resources are requested that may be temporarily unavailable. Gilles > If you continue to read your link to "Effective Java", the use of > "Optional" is suggested as the proper alternative to a checked exception. > And to be honest I'd be all for that - on a new code base. But you'd still > need figure out the "canCompute" to make the distinction between the two > states. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
