Hacker News new | ask | show | jobs
by ipsi 190 days ago
The Java one can actually be quite helpful, for a couple of reasons:

1. It tells you which variable is null. While I think modern Java will include that detail in the exception, that's fairly new. So if you had `a.foo(b.getBar(), c.getBaz())`, was a, b, or c null? Who knows!

2. Putting it in the constructor meant you'd get a stack trace telling you where the null value came from, while waiting until it was used made it a lot harder to track down the source.

Not applicable to all situations, but it could be genuinely helpful, and has been to me.

1 comments

In actual Java-Java (as opposed to Kotlin or something), first line of defense should be a linter that tries to prove nullability properties. In situations where that doesn't work, well, I think I'm the world's only fan of Java's assert keyword. If you can't use assert the language feature, you can at least throw AssertionError, which is a non-Exception Throwable subclass that's more likely to make your program die instantly, as it should, instead of treating the contract violation as a recoverable condition.