Is Java assert broken?

Question

While poking around the questions, I recently discovered the assert keyword in Java. At first, I was excited. Something useful I didn\'t already know! A more

Answer 1

I think its the way assert usage is interpreted and envisioned.

If you really want to add the check in your actual production code, why not use If directly or any other conditional statement?

Those being already present in language, the idea of assert was only to have developer's add assertions only if they don't really expect this condition to ever happen.

E.g checking an object to be null, let's say a developer wrote a private method and called it from two places (this is not ideal example but may works for private methods) in the class where he knows he passes a not null object, instead of adding unnecessary check of if since as of today you know there is no way object would be null But if someone tomorrow calls this method with null argument, in developer's unit testing this can be caught due to presence of assertion and in final code you still don't need an if check.

Answer 2

Use an assert if you're willing to pay $1 to your end-user whenever the assertion fails.

An assertion failure should be an indication of a design error in the program.

An assertion states that I have engineered the program in such a way that I know and guarantee that the specified predicate always holds.

An assertion is useful to readers of my code, since they see that (1) I'm willing to set some money on that property; and (2) in previous executions and test cases the property did hold indeed.

My bet assumes that the client of my code sticks to the rules, and adheres to the contract he and I agreed upon. This contract can be tolerant (all input values allowed and checked for validity) or demanding (client and I agreed that he'll never supply certain input values [described as preconditions], and that he doesn't want me to check for these values over and over again). If the client sticks to the rules, and my assertions nevertheless fail, the client is entitled to some compensation.

Answer 3

assert is a useful piece of Design by Contract. In that context, assertions can be used in:

• Precondition checks.
• Postcondition checks.
• Intermediate result checks.
• Class invariant checks.

Assertions can be expensive to evaluate (take, for example, the class invariant, which must hold before and after calling any public method of your class). Assertions are typically wanted only in debug builds and for testing purposes; you assert things that can't happen - things which are synonymous of having a bug. Assertions verify your code against its own semantics.

Assertions are not an input validation mechanism. When input could really be correct or wrong in the production environment, i.e. for input-output layers, use other methods, such as exceptions or good old conditional checks.

Answer 4

Java's assertions aren't really made for argument validation - it's specifically stated that assertions are not to be used instead of dear old IllegalArgumentException (and neither is that how they are used in C-ish languages). They are more there for internal validation, to let you make an assumption about the code which isn't obvious from looking at it.

As for turning them off, you do that in C(++), too, just that if someone's got an assert-less build, they have no way to turn it on. In Java, you just restart the app with the appropriate VM parameters.

Answer 5

This sounds about right. Assertions are just a tool that is useful for debugging code - they should not be turned on all the time, especially in production code.

For example, in C or C++, assertions are disabled in release builds.

Answer 6

Assertions are to indicate a problem in the code that may be recoverable, or as an aid in debugging. You should use a more destructive mechanism for more serious errors, such as stopping the program.

They can also be used to catch an unrecoverable error before the application fails later in debugging and testing scenarios to help you narrow down a problem. Part of the reason for this is so that integrity checking does not reduce the performance of well-tested code in production.

Also, in certain cases, such as a resource leak, the situation may not be desirable, but the consequences of stopping the program are worse than the consequences of continuing on.