Le jeu. 29 juin 2023 à 17:42, Elliotte Rusty Harold
<elh...@ibiblio.org> a écrit :
>
> On Thu, Jun 29, 2023 at 10:48 AM Gilles Sadowski <gillese...@gmail.com> wrote:
>
> > The situation is recoverable from the caller's POV, by performing a
> > *new* call, with a correct argument. We certainly don't need a special
> > kind of exception[1] to handle this situation. What's wrong with catching
> > a "RuntimeException" if you know how to try again?
> >
>
> The problem isn't with catching a RuntimeException. The problem is
> with *not* catching the RuntimeException because the compiler doesn't
> make you do this, and the programmer forgets.
Yes, but I handled that case from the outset: If the programmer forgets,
that is a bug! And this kind of bug has no particular status wrt any other
bug (that would throw a "RuntimeException" and make the program crash
anyways if the "try/catch" block is missing).
If "no crash" is an application requirement, it probably should be ensured
through appropriate coverage (unit/fuzzy testing).
>
> Checked exceptions are for cases that SHOULD have an error handler,
> and simply makes the omission of one an easy-to-fix compile time error
> instead of a hard-to-fix runtime error.
In most cases, the sense that lower-level code is able to tell "you might
want to handle this" leads to every function advertising "Exception", just
in case some new "advice" might be deemed useful in the future; then
the cure to calling such a painful library is
---CUT---
try {
callPainfulLibrary(someArgs);
} catch(Exception e) {
thrown new RuntimeException(e);
}
---CUT---
>
> If the code in question shouldn't have an error handler, typically
> because the code in question is buggy and should be fixed so that the
> exception is never thrown in the first place, then a runtime exception
> is appropriate.
>
That's the part on which almost all agree except the writers of "painful"
libraries. ;-)
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
