///ark

“Do not use assertions for argument checking in public methods.

Argument checking is typically part of the published specifications (or contract) of a method, and these specifications must be obeyed whether assertions are enabled or disabled. Another problem with using assertions for argument checking is that erroneous arguments should result in an appropriate runtime exception (such as IllegalArgumentException, IndexOutOfBoundsException, or NullPointerException). An assertion failure will not throw an appropriate exception. “

I’m not sure I like having a @NotNull annotation in Java – it seems a little clunky (i.e. too verbose) compared to my syntax suggestion. It does have the advantage of not changing the syntax of the language, so I suppose it is more likely such an approach would eventually be adopted.

Considering the bigger picture, the fact that languages, especially more recent ones, are adding special syntax for handling nulls or for supporting nullable types shows that this is an important issue.

You also don’t need to change Java this way.

asserting(customer != null) {
List orders = customer.getOrders();
asserting(orders != null) {
for(order : orders) {
…
}
}
}

Then you get fail-fast and degrade-gracefully in a fairly
readable format.

BTW, Groovy has a ‘?’ notation for handling nulls. So:

customer?.orders?.itemAt(1)

would return null if either customer or orders were null.

Kit

In Groovy there is something called a safe dereference operator:

customer?.getOrders().each{ it ->
…
}

The getOrders method on customer won’t be called if customer is null.