Adopt good practice or not?

Question

Is it good to use Assert for function parameters to ensure their validity? I was looking at the Spring Framework source code, and I noticed that they use Assert.notNull . Here is an example

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

Here is 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, Assert.notNull (not an assert ) is defined in the 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, statements are no different from many other runtime checks.

For example, Java bound checks all calls to the array at runtime. Does that make things a little slower? Yes. This is useful? Absolutely! As soon as the violation is violated, an exception occurs and the programmer is warned of any possible error! Behavior in other systems where array calls are not tied to verification is MORE DIRECT! (often with disastrous consequences!).

Statements, whether you use a library or language support, are similar in spirit. There are performance costs, but it's worth it. In fact, statements are even more valuable because they are explicit, and he links the concepts of a higher level.

Used correctly, the cost of productivity can be minimized and the value for the client (who would rather catch contract violations than later) and the developers (since the contract is self-service and self-documenting) is maximized.

Another way to look at this is to think of statements as “active comments.” There is no argument that the comments are useful, but they are PASSIVE; computationally they do nothing. Formulating some concepts as statements instead of comments, they become ACTIVE. In fact, they should be at runtime; violations will be caught.

---

See also: benefits of programming with statements

Answer 2

These statements are provided in the library and do not match the built-in assert keyword.

Here's the difference: assert does not run by default (they must be enabled with the -ea ), and assertions provided by the assert class cannot be disabled.

In my opinion (for what it's worth), this is also a good method, like any for checking parameters. If you used inline statements as the title of the question, I would object to it on the assumption that the necessary checks should not be removed. But this method boils down to:

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

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

The built-in statement style is more useful for situations where the condition must always be true or for private methods. There are some good recommendations in the reference book , which are presented mainly by me.

Answer 3

Yes, this is a good practice.

In the case of Spring, this is especially important because validations validate property parameters, etc., which usually come from XML posting files. In other words, they check the webapp configuration. And if you ever do any serious Spring development, these checks will save you hours of debugging when you make a stupid configuration error.

But note that there is a big difference between the Assert library class and the Java Assert keyword, which is used to define a Java statement. The last form of statements can be disabled at application startup time and should NOT be used to verify the validation of arguments that you always want to execute. It's clear that Spring designers believe that it would be a very bad idea to disable the Webapp configuration health check ... and I agree.

UPDATE

In Java 7 (and later), the java.util.Objects class provides the requireNonNull method of checking if the argument is null and throw an exception. You use it as follows:

  SomeType t = ... SomeType tChecked = Objects.requireNonNull(t); 

or

  SomeType tChecked = Objects.requireNonNull(t, "t should be non-null"); 

However, note that this method raises a NullPointerException , not an IllegalArgumentException .

Answer 4

Based on the Sun guide on statements, you should not use statements to test arguments in public methods.

Validation of arguments is usually part of the published specifications (or contract) of the method, and these specifications must be executed whether statements are enabled or disabled.

Answer 5

On very large and poorly designed / supported systems, if you want to improve predictability in methods that, say, last 6,000 lines, and no one else understands them, it may be useful to use the assert keyword to cause development environments to explode when errors are detected. But if you implemented these claims in production, you could build a patch that, although it was conceived, fixed the problem. You want to fix this bad patch by opening it in a dev environment, not in production. This way you can enable claims during development and disable them during production.

Another valid use of the assert keyword during development is to insert validation checks into algorithms that must be run in submillisecond times and are reasonably well isolated from unpredictable or unverified subscribers. In this case, you cannot afford to keep the reality check in production, although it is still very useful in development. On the other hand, if the source of the parameters that you check is unpredictable or may become such (if it is partially determined due to user input, for example), you will probably never be able to skip checking even during production and should accept a performance hit as the cost of doing business. (In this latter case, you probably won’t want to use assert.) But you should choose statements to exclude validation of production time only after profiling tells you that you simply cannot afford the overhead.

Answer 6

Yes, that's a good idea. You execute a contract by interface or class. If there is a breach of contract, you want to detect it as soon as possible. The longer you wait, the more unpredictable the results may be and the more difficult it is to diagnose.

When you explicitly verify this, you should also provide an informational message that, when viewed in a log file, can provide useful context to help find the root cause, or even just realize that you made the wrong assumption about what the contract is.

Answer 7

I save my statements in the released binaries , but with a modified behavior: abort is not called, but the stack is being built.

More details here: http://blog.aplikacja.info/2011/10/assert-to-abort-or-not-to-abort-thats-the-question/