this post was submitted on 06 Nov 2025
17 points (74.3% liked)
Programming
23417 readers
209 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
But you should just throw an exemption, and let the caller handle it. There is so many variations where an object is null, you can't control, or you are deep inside your own code, it should be covered by a test.
The problem is that when an project is too big and a method is called from multiple contexts it's very easy to lose track of the context where the null check has been done and where it hasn't. This leads to a lot of duplicated null checks around the project and the constant paranoia of "can this be null here?".
A much better way of doing this is using the
Optionalwhen an Object can be "null" and a direct instance where it cannot. This way, at any given context you know for absolute sure if a null check is needed or not. However, even with annotations this does not throw a compile error...