Le lun. 3 juil. 2023 à 09:41, Alex Herbert <alex.d.herb...@gmail.com> a écrit :
>
> On Mon, 3 Jul 2023 at 08:29, sebb <seb...@gmail.com> wrote:
> >
> > Is null checked or unchecked?
> >
> > I think neither, so isUnchecked also needs to check for null.
> >
> > I wonder whether it might be better to throw NPE in both cases for null.
> >
> > It may be confusing for users if not checked != unchecked.
> > e.g. it is tempting to code:
> >
> > if (isChecked(t)) {
> > } else { // must be unChecked
> > }
> >
> > If we don’t throw NPE, then it needs to be made very clear that
> > isChecked and isUnchecked are not opposites, there is a 3rd case.
> >
> > In any case, there needs to be a unit-test specifically for null.
> >
> > Sebb
>
> +1
>
> I reiterate what I originally said, this is missing:
>
> @Test
> public void testIsUnchecked_null() {
> assertFalse(ExceptionUtils.isUnchecked(null));
> }
>
> The method implementation details are secondary to the fact that the
> code is not clear on how it handles null; the relationship between
> isChecked and isUnchecked; and the intended usage.
>
> Note that one possible usage of type determination is to decide if you
> can cast it to a certain type. Currently this method does not provide
> this functionality as isUnchecked does not ensure that a cast to
> RuntimeException is allowed (since it passes for Error). So my use
> case is satisfied by instanceof. This leaves me wondering what are the
> use cases for isChecked or isUnchecked. I presume you are in an
> exception block with a Throwable of unknown type. So why do you care
> if the exception is not checked if not for a recast?
>
> Without a use case not satisfied by instanceof then this is code bloat.
>
Reading through the discussion, I was wondering the same (What is
the use case?) and was tempted to reach the same conclusion.
After all, isn't "try/catch" the standard way to tailor behaviour according
to the exception type?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
