annotation for JUnit

[Jon Schewe]

The checker framework is issuing warnings about possibly null values being passed to "assertNotNull" in the JUnit framework. My first thought is that the JUnit framework needs annotations to note that it's OK for these parameters to be null as that's what the framework is testing for. Is that in line with the philosophy of the checker framework authors?

Thanks,

Jon

[Michael Ernst]

Jon-

If you are using the Nullness Checker, that probably means that you do not want your program to crash.  Your users probably don't care whether the crash happens within your code or within a call to assertNotNull().

This is discussed in section 2.4.3, "Annotations indicate non-exceptional behavior", of the manual.  (If you search for "assertNotNull" in the manual, that section is the first match.)
Please let us know if you have questions or suggestions about that manual section.

Mike

--

---
You received this message because you are subscribed to the Google Groups "Checker Framework discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to checker-framework-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/checker-framework-discuss/ce239d4d65bb361729d53ac4d5c91cf652c2260b.camel%40mtu.net.

[Durchholz, Joachim]

JUnit tests aren’t running for the user, they’re running on the developer machine or during build, so I believe that the usual advice doesn’t apply 1:1.

(Even if the code contains a run-time nullness check, you typically catch the crash and tell the user what failed, you don’t crash the application – throwing NPEs during operation, while clearly a bug, is a very useful mode of defensive programming. We’re doing this all the time here, and see the nullness checker as a way to reduce defensive code, not as a complete elimination of NPEs.)

 

My own take would be that the nullness checker is telling you about unit tests that you don’t need because the nullness checker would warn you about these in your production code anyway.

I have two reasons why I’d like to hear if this idea is valid though:

• I might be misunderstanding in general, so does this mode of thinking hold water at all?
• I have no idea how the situation changes if the nullness checker is imprecise.

 

Regards,

Jo

To view this discussion on the web visit https://groups.google.com/d/msgid/checker-framework-discuss/CAAJCdQTp7jcZqOAm8OnhCjjZ5sp-sQQ86meaexnFiNHjyxV2Lw%40mail.gmail.com.

 

Sensitivity: C2 Internal

The content of this e-mail is intended only for the confidential use of the person addressed.
If you are not the intended recipient, please notify the sender and delete this e-mail immediately.
Thank you.

[Jon Schewe]

Thank you for the pointer in the manual. The suggestion to not run the checker on test code might be the best.

The reason that I have assertNotNull checks in many cases is too check that the test resurfaces are properly available and if not fail with a reasonable error message. Right now misty of my calls to assertNotNull are triggering the nullness checker.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.