--
---
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.
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:
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.