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 efficient way for me to check the validity of input parameters! Yay learning!

But then I took a closer look, and my enthusiasm was not so much "tempered" as "snuffed-out completely" by one simple fact: you can turn assertions off.*

This sounds like a nightmare. If I'm asserting that I don't want the code to keep going if the input listOfStuff is null, why on earth would I want that assertion ignored? It sounds like if I'm debugging a piece of production code and suspect that listOfStuff may have been erroneously passed a null but don't see any logfile evidence of that assertion being triggered, I can't trust that listOfStuff actually got sent a valid value; I also have to account for the possibility that assertions may have been turned off entirely.

And this assumes that I'm the one debugging the code. Somebody unfamiliar with assertions might see that and assume (quite reasonably) that if the assertion message doesn't appear in the log, listOfStuff couldn't be the problem. If your first encounter with assert was in the wild, would it even occur to you that it could be turned-off entirely? It's not like there's a command-line option that lets you disable try/catch blocks, after all.

All of which brings me to my question (and this is a question, not an excuse for a rant! I promise!):

What am I missing?

Is there some nuance that renders Java's implementation of assert far more useful than I'm giving it credit for? Is the ability to enable/disable it from the command line actually incredibly valuable in some contexts? Am I misconceptualizing it somehow when I envision using it in production code in lieu of statements like if (listOfStuff == null) barf();?

I just feel like there's something important here that I'm not getting.

*Okay, technically speaking, they're actually off by default; you have to go out of your way to turn them on. But still, you can knock them out entirely.

---

Edit: Enlightenment requested, enlightenment received.

The notion that assert is first and foremost a debugging tool goes a long, long way towards making it make sense to me.

I still take issue with the notion that input checks for non-trivial private methods should be disabled in a production environment because the developer thinks the bad inputs are impossible. In my experience, mature production code is a mad, sprawling thing, developed over the course of years by people with varying degrees of skill targeted to rapidly changing requirements of varying degrees of sanity. And even if the bad input really is impossible, a piece of sloppy maintenance coding six months from now can change that. The link gustafc provided (thanks!) includes this as an example:

assert interval > 0 && interval <= 1000/MAX_REFRESH_RATE : interval;

Disabling such a simple check in production strikes me as foolishly optimistic. However, this is a difference in coding philosophy, not a broken feature.

In addition, I can definitely see the value of something like this:

assert reallyExpensiveSanityCheck(someObject) : someObject;

My thanks to everybody who took the time to help me understand this feature; it is very much appreciated.

Faceplate

This looks a lot like a rant, and not like a question at all. – Sedition

Have you ever used ASSERTs in C or C++? Have you ever wished you could turn them on or off at the snap of a finger? – Lewallen

@Joachim: Understood, but seriously, I'm here looking for enlightenment. This feature really does seem broken to me -- but that feels on par with saying "I don't see what's wrong with my code, therefore the compiler must be broken!", just on a higher level. I really feel like I'm missing something. If you can suggest a way for me to express WHY the feature strikes me as broken that doesn't strike you as a rant, I'm listening. – Faceplate

The enlightenment you are looking for is this: assertions are to aid debugging, not to be part of production code. – Bekelja

@DJClayworth: That distinction does indeed make asserts seem MUCH more viable in my own head, thank you. – Faceplate

You may be interested to know that .Net now has a feature similar to this which verifies arguments at compile time (where it can), meant for actual production. – Zak

An assert is little more than an "executable comment". As such it has some small nonzero value to the future reader of the code. – Oneiromancy

See also Bertrand Meyer's paper comparing design by contract with defensive programming, addressing the issue of 'redundant' checks. – Xavier

Pedagogic question and answer in one post! – Statue

Answer 1

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.

Altostratus

Answer 2

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.

Inauspicious

That's not quite what the link says. It says they're not to be used for argument validation in PUBLIC methods -- it explicitly gives an example of using them for argument validation in PRIVATE ones. And for making assumptions about the code that isn't obvious, isn't that typically the job of comments? Didn't know that about C/C++, though; I definitely see how turning them on via command-line switch is more appealing than doing a full recompile. – Faceplate

Yes, you can use asserts for certain private methods. But there should be no invalid calls to those private methods in production (if you can't guarantee this, use exceptions or another mechanism). That page explicitly says that asserts should be used for documenting assumptions, rather than comments. See the i % 3 == 2 example. – Zepeda

Answer 3

Every language I've ever seen with assertions comes with the capability of shutting them off. When you write an assertion you should be thinking "this is silly, there's no way in the universe this could ever be false" -- if you think it could be false, it should be an error check. The assertion is just to help you during development if something goes horribly wrong; when you build the code for production you disable them to save time and avoid (hopefully) superfluous checks

Gstring

I think it's a difference in philosophy that tripped me up. For me, sanity checking the input params isn't a commentary on whether or not they COULD be wrong; it's saying that this method needs them not to be wrong. Sure, I may think the bad inputs are impossible, but what do I know? The code base is huge, my understanding of it is incomplete, and at some point in the future some idiot (like, you know, me) could make the bad inputs possible again. But having said that, I see the value of being able to turn the expensive checks on or off. – Faceplate

"it should be an error check": you mean, an error in the program input data, rather than a check for an error in the program itself? – Marijuana

Answer 4

Assertions are meant to ensure things you are sure that your code fulfills really are fulfilled. It's an aid in debugging, in the development phase of the product, and is usually omitted when the code is released.

What am I missing?

You're not using assertions the way they were meant to be used. You said "check the validity of input parameters" - that's precisely the sort of things you do not want to verify with assertions.

The idea is that if an assertion fails, you 100% have a bug in your code. Assertions are often used for identifying the bug earlier than it would have surfaced otherwise.

Cellobiose

"you 100% have a bug in your code": in the code itself, or in the code of the assertion check. – Marijuana

Answer 5

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.

Kassey

This places more faith in the completeness (or existence!) of unit tests than I think is wise, but nevertheless, I see the logic of it. :-) Thank you. – Faceplate

Answer 6

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.

Padraic

Answer 7

Assertions are really a great and concise documentation tool for a code maintainer.

For example I can write:

foo should be non-null and greater than 0

or put this into the body of the program:

assert foo != null;
assert foo.value > 0;

They are extremely valuable for documenting private/package private methods to express original programmer invariants.

For the added bonus, when the subsystem starts to behave flaky, you can turn asserts on and add extra validation instantly.

Muraida

Answer 8

If asserts could not be turned off, then why should they even exist.

If you want to performa validity check on an input, you can easily write

if (foobar<=0) throw new BadFoobarException();

or pop up a message box or whatever is useful in context.

The whole point of asserts is that they are something that can be turned on for debugging and turned off for production.

Fishy

Answer 9

Assertions aren't for the end user to see. They're for the programmer, so you can make sure the code is doing the right thing while it's being developed. Once the testing's done, assertions are usually turned off for performance reasons.

If you're anticipating that something bad is going to happen in production, like listOfStuff being null, then either your code isn't tested enough, or you're not sanitizing your input before you let your code have at it. Either way, an "if (bad stuff) { throw an exception }" would be better. Assertions are for test/development time, not for production.

Monitor

Answer 10

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.

Xavier

It’s weird to frame putting in extra effort to make the program more robust as making a you-can-only-lose-or-gain-nothing bet. Java asserts were implemented in order to make Java programmers more likely to add sanity checks, not to encourage heightened crash sqeaumishness. – Statue

“(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)”—A perverse incentive (refer to the bet). Never use asserts for input from those shady one dollar clients. – Statue

Answer 11

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.

Cyprus

I don't agree that assertions should be used for recoverable errors that are expected to occur in production. That's generally what checked exceptions are for. In some cases, though, neither exceptions nor assertions are appropriate. – Zepeda

Answer 12

This doesn't directly answer your question about assert, but I'd recommend checking out the Preconditions class in guava/google-collections. It allows you to write nice stuff like this (using static imports):

// throw NPE if listOfStuff is null
this.listOfStuff = checkNotNull(listOfStuff);

// same, but the NPE will have "listOfStuff" as its message
this.listOfStuff = checkNotNull(listOfStuff, "listOfStuff"); 

It seems like something like this might be what you want (and it can't be turned off).

Daumier