yes. You are right. Closed
On Mon, 3 Jul 2023 at 10:12, Gilles Sadowski <gillese...@gmail.com> wrote:
> 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
>
>
