I should clarify...

The use of ["rawtypes", "unchecked"] are quite common in test code and
"unused" is common in API/Framework (production) code

While *tests* make more liberal use of these checks  ("unused" is
questionable (!), though), I think all of these checks should be used
judiciously in production code.

-j


On Fri, May 8, 2020 at 12:50 PM John Blum <jb...@pivotal.io> wrote:

> @Donal -
>
> Well, if you have code like...
>
> public void someMethod(@Nullable Object value) {
>
>     Assert.notNull(value, "...");
>
>     value.invokeSomeMethod();
>
>     ...
> }
>
> The compiler will often *warn* you that value might be null without a
> proper null check.  That is, not all IDEs recognize "valid" null checks,
> particular if they are using some API/framework like AssertJ, perhaps.  For
> example:
>
> assertThat(value).isNotNull();
>
> NOTE: *AssertJ* use is valid and common outside of just tests!
>
> Usually the compiler only recognizes the assert keyword, i.e. ...
>
> assert value != null : "...";
>
> But the problem with Java assertions is you need to explicitly enable
> them, therefore most users use lib or framework/API (e.g. like *AssertJ*).
>
> I think other valid uses of the @SuppressWarnings annotation includes.
>
> *"rawtypes"*
> *"unchecked"* // particular around casting when the compiler is not smart
> enough to figure it out though you know it is safe; usually an instanceof
> check avoids these...
> *"unused"* // arguable, though
>
> Of course, use all of these judiciously and only when absolutely necessary
> or certain.
>
> I don't think it is OK to suppress deprecations (among other warnings)
> since those should be addressed!
>
> -j
>
>
> On Fri, May 8, 2020 at 12:44 PM Jacob Barrett <jbarr...@pivotal.io> wrote:
>
>>
>>
>> > On May 8, 2020, at 12:41 PM, Donal Evans <doev...@pivotal.io> wrote:
>> >
>> > Is there a consensus on what constitutes a benign warning? I think the
>> only
>> > times I use @SuppressWarnings is in parameterized tests to suppress the
>> > unused method warning for the parameters method, or for unchecked
>> casts, as
>> > below:
>> >
>> > PartitionedRegion detailRegion1 = mock(PartitionedRegion.class);
>> > when(cache.getRegion(regionPath1)).thenReturn(detailRegion1);
>> >
>> > where the thenReturn() would complain, since it's expecting to return a
>> > Region<Object, Object>.
>> >
>> > Would these be considered things that could safely just be ignored (and
>> so
>> > for which I can turn off inspection), or is the use of @SuppressWarnings
>> > here warranted?
>>
>> This is a legitimate suppression. There is no other way to correct the
>> dysfunctional nature of Java Generics than to @SuppressWarnings. In this
>> case though only that statement should be suppressed.
>>
>> -Jake
>>
>>
>
> --
> -John
> Spring Data Team
>


-- 
-John
Spring Data Team

Reply via email to