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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
