Assert a good practice or not?

Question

Is it a good practice to use Assert for function parameters to enforce their validity. I was going through the source code of Spring Framework and I noticed that they use Assert.notNull a lot. Here's an example

public static ParsedSql parseSqlStatement(String sql) {     Assert.notNull(sql, "SQL must not be null"); } 

Here's Another one:

public NamedParameterJdbcTemplate(DataSource dataSource) {     Assert.notNull(dataSource,             "The [dataSource] argument cannot be null.");     this.classicJdbcTemplate = new JdbcTemplate(dataSource); }  public NamedParameterJdbcTemplate(JdbcOperations classicJdbcTemplate) {     Assert.notNull(classicJdbcTemplate,             "JdbcTemplate must not be null");     this.classicJdbcTemplate = classicJdbcTemplate; } 

FYI, The Assert.notNull (not the assert statement) is defined in a util class as follows:

public abstract class Assert {     public static void notNull(Object   object, String   message) {       if (object == null) {           throw new IllegalArgumentException  (message);       }    } } 

Answer 1

In principle, assertions are not that different from many other run-time checkings.

For example, Java bound-checks all array accesses at run-time. Does this make things a bit slower? Yes. Is it beneficial? Absolutely! As soon as out-of-bound violation occurs, an exception is thrown and the programmer is alerted to any possible bug! The behavior in other systems where array accesses are not bound-checked are A LOT MORE UNPREDICTABLE! (often with disastrous consequences!).

Assertions, whether you use library or language support, is similar in spirit. There are performance costs, but it's absolutely worth it. In fact, assertions are even more valuable because it's explicit, and it communicates higher-level concepts.

Used properly, the performance cost can be minimized and the value, both for the client (who will catch contract violations sooner rather than later) and the developers (because the contract is self-enforcing and self-documenting), is maximized.

Another way to look at it is to think of assertions as "active comments". There's no arguing that comments are useful, but they're PASSIVE; computationally they do nothing. By formulating some concepts as assertions instead of comments, they become ACTIVE. They actually must hold at run time; violations will be caught.

---

See also: the benefits of programming with assertions

Answer 2

Those asserts are library-supplied and are not the same as the built-in assert keyword.

There's a difference here: asserts do not run by default (they must be enabled with the -ea parameter), while the assertions provided by the Assert class cannot be disabled.

In my opinion (for what it's worth), this is as good a method as any for validating parameters. If you had used built-in assertions as the question title implies, I would have argued against it on the basis that necessary checks should not be removable. But this way is just shorthand for:

public static ParsedSql parseSqlStatement(String sql) {     if (sql == null)         throw new IllegalArgumentException("SQL must not be null");     ... } 

... which is always good practice to do in public methods.

The built-in style of asserts is more useful for situations where a condition should always be true, or for private methods. The language guide introducing assertions has some good guidelines which are basically what I've just described.