Informal Survey on the Use of Assert

[Dirk Schreckmann]

Are you using the assert keyword, introduced with Java 2 v 1.4, when programming?

If not, why not?

[Ben Wood]

No, I am not using assertions. In truth I wasn't even really aware of assertions until I started to read up for the SCJP exam, which is partly why I am not using them I have yet to find time to sit down and try them out properly on a project.

[Ilja Preuss]

No, we are not using assertions, but our own Ensure class. Several reasons:

- part of our code has to compile with JDK1.3
- we actually don't want our assertions to be disableable
- we throw different Exceptions based on wether a precondition, invariant etc. failed

[Peter den Haan]

We use it to run some potentially expensive class invariant tests.

- Peter

[Ernest Friedman-Hill]

Same as Ilja, on one major project we've got our own "Debug" class with assert methods; we've kept using it for 1.3 compatibility. We've about to jettison 1.3, however, and so may move to using Java assert.

[Mike Southgate]

Now and again. Really only where I think there are real possibilities of errors. Trouble is that's hard to predict, of course, so how do you know where and how many to insert?

ms

[fred rosenberger]

We used to use them in our C++ days. One of our senior developers was a STRONG advocate of them.

We merged with another company, and that developer left. The new company had a large code base we started working on, with no asserts in it. Since nobody is pushing for them, they're not being used.

[Ilja Preuss]

Originally posted by fred rosenberger:
We used to use them in our C++ days. One of our senior developers was a STRONG advocate of them.

We merged with another company, and that developer left. The new company had a large code base we started working on, with no asserts in it. Since nobody is pushing for them, they're not being used.

That's interesting. Did you notice any difference in bug density?

[fred rosenberger]

Did you notice any difference in bug density?

There are several ways i could answer that question. the easiest is "i have no idea". i'm a fairly low-level programmer here, and don't get to see the kind of stats that would tell me.

I think i'm seeing a lot more bugs, but i've also gone from working on a fairly stable, released version of a mature product written in C++ to a brand new version being written in Java.

Most of the bugs i see i don't think would have been fixed/caught with asserts, but i could (and probably am) wrong in my belief of that.

[Ilja Preuss]

Originally posted by fred rosenberger:
i'm a fairly low-level programmer here, and don't get to see the kind of stats that would tell me.

Uh, how does that work out for you?

Most of the bugs i see i don't think would have been fixed/caught with asserts, but i could (and probably am) wrong in my belief of that.

Ok, thanks for the info, anyway!

[Joe Ess]

When I was doing C++, assertions were one of the few features I never used. If something is an error condition, I would think it would be an error condition in both testing (where assertions are turned on) and production (where assertions are turned off). I've ignored it since it crept into Java. Here's hoping that generics will trump my lackluster experience with STL.

[Peter Chase]

We use our own 1.3-compatible assertions, but lots of them. I think they are invaluable for checking internal consistency of a program and the assumptions on which they are built. They are particularly good during maintenance of an established program, as they can tell you when you've violated some assumption made by an earlier developer.

I am surprised so many people don't use them. I guess there are two possibilities: -

People are not doing the sort of internal state checks that are done with assertions. This means that they will find errors later and with more difficulty (cost).

People are doing internal checks, but they are being done at all times, rather than just during development and testing. This is probably OK, most of the time, but might have some impact on performance of final code.

Don't forget that assertions (whether Java "assert" or something else) can be used to do quite complicated checks, which would be too expensive in released code. For instance, if you have two data structures giving different views of the same data, you can frequently check they have the same content, in asserted code, but avoid the cost of that (once you're sure the bugs have been killed) in your released code.

[David Hibbs]

Answer 1 (Reasonable answer) :
Not using them. WAS 5.0 (our current platform) runs on JDK 1.3 (STILL) so they're not supported.

Answer 2 (Rant) :

I'll never use them and think they're the single largest mistake made in the design and planning of the Java language. I think this for several reasons.

a) If you have to turn it on twice to get the asserts to work (compiler AND runtime), who will really take the time use it? Once at compile time OR at runtime would be nice. Runtime only would be great, as per the logging frameworks that are now commonplace (log4j, commons, etc). Double requirements is double the hurdle to using them *effectively*.

b) If you're going to write assumption checks, why be lazy?

c) It's simply a throwback to C days. When I was a C/C++ developer, I saw many many many asserts in code. The result was that, inevitably, the program would fail and exit with a helpful message "Assertion Failed". I've seen it on my WinTel laptop in commercial software, too... "Assertion Failed in abcXyz.dll." Because you can use assert anywhere without regard to putting thought into where the exception will go, who will handle it, or what the result will be, the more assertions there are the more unstable the software is (barring a). In C, assertions were used because there was no other good way to handle an error condition. In C++ and Java, we have these things called "Exceptions".

If an assumption is invalid, throw as SPECIFIC an exception as possible indicating what happened. Put it in the method signature for cryin' out loud, so everyone calling it KNOWS it might blow up. This is the whole reason that the Java exception model was developed--don't kludge it! Use it so that you can trace what happened. Use it so that other developers understand what errors may occur in a call.

Just because a feature is available doesn't mean you should use it.

(Aside: I know someone will ask next about typesafe ENUMs. I don't feel the same way about those -- I like the fact that they've been included!
The difference is that there is no clean parallel solution in Java, unlike the assert vs. exception comparison.)

Ahem. Anyway, end rant.

[Peter den Haan]

Originally posted by David Hibbs:
a) If you have to turn it on twice to get the asserts to work (compiler AND runtime), who will really take the time use it?

I'm not sure I get you. What do you mean with turning it on at compile time? Using the -source 1.4 option to indicate that you're happy writing JDK 1.4 specific source? But surely that's a one-time thing; ten seconds of setup in a build script or development environment. Who cares about that kind of time?

Having to enable them at run time is exactly the point of assertions, of course.

b) If you're going to write assumption checks, why be lazy?

What do you mean?

c) It's simply a throwback to C days. [...] Because you can use assert anywhere without regard to putting thought into where the exception will go, who will handle it, or what the result will be, the more assertions there are the more unstable the software is (barring a).

That'd simply be misuse of Java assertions. They are a development and testing tool. If you want to keep your checks around in production, use plain old Java code and think carefully about how you are going to handle them. I don't see how this is a problem with the assertion facility.

[...] In C, assertions were used because there was no other good way to handle an error condition. In C++ and Java, we have these things called "Exceptions".

This remark I don't understand at all. An assertion is just a fancy way to throw an exception (well, an Error actually). Not sure what your point is here, unless it would be that you do want your checks to always run, including in production. If that is what you want, then assertions are simply not the tool for it! You seem to be blaming a screwdriver for being poor at hammering nails into the wall. We've had hammers for that since JDK 1.0...

If an assumption is invalid, throw as SPECIFIC an exception as possible indicating what happened. Put it in the method signature for cryin' out loud, so everyone calling it KNOWS it might blow up.

I could not disagree more. Checked exceptions are not a good way to flag up programming errors. Traditionally, RuntimeExceptions have been used for these (IndexOutOfBoundsException, IllegalArgumentException, etc). Such disastrous errors typically cannot and should not be handled in a fine-grained way, but allowed to bubble up unchecked until some top-level dispatch loop or error handler which can display an error message and/or retry the entire operation. With the assertion facility we've also got AssertionError for testing-only checks which by definition don't need sophisticated handling at all.

I must say I do like assertions a lot. They aren't, and don't want to be, a universal way to check all of your preconditions, postconditions and invariants all the time. They are a straightforward way to embed those checks that are worthwhile to have as testing and documentation, but either too strict or too expensive to perform in production.

- Peter
[ September 09, 2004: Message edited by: Peter den Haan ]

[fred rosenberger]

Originally posted by Ilja Preuss:

Uh, how does that work out for you?

Pretty well, actually. Since i am rather insecure in my abilities, it's a comfortable place to be. And, i fly low enough on the company radar that i never get into trouble when things are late/broken/etc.

I could go on, but I don't want to get into a whole psychoanalysis here, so i'll stop.

[Warren Dew]

I don't use asserts in Java yet, because I still deal with 1.3 code. I used to use them all the time in c and C++, generally to check every function argument in every nonprivate function (and some private ones).

I did for a while use my own Assert class with various methods (e.g., Assert.notNull(x)). Then I decided it was just as easy to check the condition with an if statement and throw an Error, or log an error, or whatever. One disadvantage: I don't use them quite as much, because the syntax is less convenient.

I will probably use them a lot more when I've moved solidly to 1.4. I haven't checked, but I hope the syntax is as convenient as C++, and there are some situations where I do care about the efficiency of leaving them out for release code.

[David Hibbs]

Before I begin, do keep in mind that I did day that it was a rant. I'll do my best to answer and clarify in less-than-ranting form, though.

Originally posted by Peter den Haan:
I'm not sure I get you. What do you mean with turning it on at compile time? Using the -source 1.4 option to indicate that you're happy writing JDK 1.4 specific source? But surely that's a one-time thing; ten seconds of setup in a build script or development environment. Who cares about that kind of time?

Yes, this is exactly what I mean. Is it a language feature or not? Why do I have to specifically enable it on the compiler if it won't be enabled on the JVM anyway?

Besides... not everyone uses build scripts for every build. Eclipse by default builds on resource save. With it disabled, ctrl-b builds everything. Other IDEs have similar features. When in a development mode, a build script is not my first choice (and I know some people who wonder why even HAVE build scripts with the quality of IDEs any more).

On top of this, to enable assertions in J2EE code I'd have to enable assertions on the whole app server JVM. I don't know about you, but I don't want to have to enable/disable at that level.

Having to enable them at run time is exactly the point of assertions, of course.

Not if you refer to the C world (the origin of assertions).
Don't get me wholly wrong; I hat assertions in the C world, too.

That'd simply be misuse of Java assertions. They are a development and testing tool. If you want to keep your checks around in production, use plain old Java code and think carefully about how you are going to handle them. I don't see how this is a problem with the assertion facility.

How often have you seen tools misused?

If you want a development and testing tool, use one. There are many many of them to choose from. Assertions are merely an extraneous addition to the list.

This remark I don't understand at all. An assertion is just a fancy way to throw an exception (well, an Error actually).

Exactly. If you want to throw an exception, then throw an exception. Make it clear that that's what will happen.

You seem to be blaming a screwdriver for being poor at hammering nails into the wall.

No, that's not what I'm saying... Assume for a second that Exceptions::Screws.

What I'm saying is that I have a screwdriver. I can take it with me anywhere and use anywhere. Why do I need a *corded* electric screwdriver that I can only use where I have access to an electrical outlet?

I could not disagree more. Checked exceptions are not a good way to flag up programming errors. Traditionally, RuntimeExceptions have been used for these (IndexOutOfBoundsException, IllegalArgumentException, etc).

OK, they're not for catching programming errors. The problem is that a lot of the time the error you're catching is not due to a programming error that you can control.

For example, I read and proces data from a database. Meanwhile, the mainframe programmers also read and process data on that database. Today everything is great. Tomorrow the mainframers make a mistake and I blow up because of a data error. When you know there may be data errors, it may make sense to use a checked exception.

If not, there's nothing stopping you from writing your own unchecked exception such as GarbageDataException extends RuntimeException.

I must say I do like assertions a lot. They aren't, and don't want to be, a universal way to check all of your preconditions, postconditions and invariants all the time. They are a straightforward way to embed those checks that are worthwhile to have as testing and documentation, but either too strict or too expensive to perform in production.

The problem is that they'll BE misused and misunderstood. Exception handling is something that newcomers have enough problems with. Why muddy the waters?

Maybe you can enlighten me on some things. If assertions are meant as a testing and documentation too...
1) Why do I want my unit tests embedded in my code base?
2) What do they accomplish for documentation that a comment line cannot?
3) Assuming that I _do_ want my unit tests embedded within my application code, why would I include a heavy or strict check to clutter the code?

Anyway, I'll close with a parting shot.
If I wanted my Java code to look and read like C/C++, I'd be writing C#.

[Daniel Mayer]

Originally posted by David Hibbs:
Yes, this is exactly what I mean. Is it a language feature or not? Why do I have to specifically enable it on the compiler if it won't be enabled on the JVM anyway?

Because of source code compatibility - Sun decided that you should be able to compile 1.3 code without any hassles.

On top of this, to enable assertions in J2EE code I'd have to enable assertions on the whole app server JVM. I don't know about you, but I don't want to have to enable/disable at that level.

That's not true, as far as I know - you can enable assertions at package granularity, at least.

How often have you seen tools misused?

I have frequently. And I typically blame the user, not the tool.

If you want a development and testing tool, use one. There are many many of them to choose from. Assertions are merely an extraneous addition to the list.

I don't see how other tools could replace assertions.

Exactly. If you want to throw an exception, then throw an exception. Make it clear that that's what will happen.

To someone knowing the language, it *should* be totally clear.

Otherwise you could argue that we shouldn't use for loops, that using if in combination with goto would have been more clear...

What I'm saying is that I have a screwdriver. I can take it with me anywhere and use anywhere. Why do I need a *corded* electric screwdriver that I can only use where I have access to an electrical outlet?

What's wrong with having both?

Why do you program in Java instead of byte code?

1) Why do I want my unit tests embedded in my code base?

Assertions are not unit tests, they are complimentary.

How would you implement the functionality of assertions without embedding them into the source code?

2) What do they accomplish for documentation that a comment line cannot?

The comment is more likely to become out of date, because it doesn't fail when it is violated.

3) Assuming that I _do_ want my unit tests embedded within my application code, why would I include a heavy or strict check to clutter the code?

I don't understand this question.

If I wanted my Java code to look and read like C/C++, I'd be writing C#.

Actually C# looks much more like Java than like C++. And it's not even a bad language.

[Warren Dew]

Obviously I've had somewhat different experiences with asserts than some of the people with this thread. As I mentioned, I've used them primarily in C and C++. I've not used them on Windows; I've used them on a variety of other platforms, especially Unix and embedded systems.

In C and C++, assert() is a macro. This has a couple of implications:

- You can define it to do what you want it to do. When I've worked with them in debug builds, they typically identify the line of source code and the condition that failed and printed out a stack trace as well. When used religiously, that is, to verify every argument of every function, they make it much easier to find the cause of unintended null pointers before they get propagated so far from their source that they become difficult to trace. This can save a significant amount of frustrating debugging.

- They can have zero impact on the production build if that's what you want. In a final production build, they are removed even before compilation, so not only do they have no direct impact on processing speed, they have no memory footprint and thus no indirect impact on processing speed either. This is important, because it means that you can scatter them liberally through your code without worrying about bogging down the final application.

- They can be redefined for various test builds. For example, on failure, they can be defined to save the error message and stack trace, along with other relevant values, to a bug report file that a beta tester can just email in. That can make it a lot easier to get useful bug reports.

So now I've read up on Java asserts, and I have to admit I'm not impressed. They can give you good information during development, true, but throwing errors can do the same thing. Since they are disabled at runtime rather than compile time, they still leave a memory footprint, which can be a performance issue when that memory has to get loaded to processor cache. And since the runtime turns them off by default, they won't be useful for getting better bug reports from beta testers.

It seems to me it's more useful to define one's own set of assertion methods, which can then be tailored for debug releases versus beta releases versus runtime releases. The only downside would be a few more characters (e.g., if you use an Assert class, Assert.isTrue() rather than just assert()).

Am I missing something here?

[ September 11, 2004: Message edited by: Warren Dew ]
[ September 11, 2004: Message edited by: Warren Dew ]

[David Hibbs]

Item #1: the compiler flag.

Originally posted by Daniel Mayer:
Because of source code compatibility - Sun decided that you should be able to compile 1.3 code without any hassles.

So... in order to use 1.4 features with a 1.4 compiler, I have to tell the 1.4 compiler that I'm compiling 1.4 code? Logical. :roll:

It would make much more sense if the compiler just worked on 1.3 code. It should all work anyway.

Item #2: Enabling assertions on an app server.

That's not true, as far as I know - you can enable assertions at package granularity, at least.

Allow me to clarify. J2EE apps run inside an app server. That app server runs inside a JVM -- the same JVM that the J2EE app is running on. In order to enable assertions, regardless of granularity, I must specify an argument at startup of the JVM. AFAIK, you cannot change your assertion setting at runtime; you can only set it at JVM start. In order to enable my assertions or change granularity, I must stop my app server, change the assertion parameter, and start my app server.

Yeah, I want to wait for WebSphere to stop and start repeatedly.

Besides this, consider a server running multiple applications all based on a common framework such as struts. If I enable assertions on the framework to trace out ONE application, I have now enabled them on ALL applications using the same framework!

#3: Tools.

I don't see how other tools could replace assertions.

I still fail to see why assertions (ala C/C++) are a necessary tool, especially given my problems with enabling them.

#4: Assertions vs. Exceptions

To someone knowing the language, it *should* be totally clear.

Looking at a line that calls assert, perhaps. But if an assertion fails in a library (for example), the caller has to then try to figure out why. Which is clearer about the root cause of a problem -- an AssertionFailedError or a NumberFormatException ?

#5: Assertions and Unit Tests

Assertions are not unit tests, they are complimentary.

How would you implement the functionality of assertions without embedding them into the source code?

I fail to see how an assertion is anything BUT a unit test if you have to enable it and then run through a process. It simply moves the validation into the code that I'm trying to validate! IMHO, If you want or need internal validation, it better not be something you can turn off!

I don't understand this question.

It was implied that there are times that you want to write a heavy test. It was also implied that this could be done with an assertion. Assuming these are both true (which they are), why would I want to make my source file larger, my functions longer or my code more cluttered by embedding testing code in it?

Consider a method with CCN 5 and length 20 lines. If I add a heavy test that takes 20 lines to write, my CCN and length are now twice what they would be if the test was external. It makes the method MUCH harder to understand and maintain.

#6 : Assertions in Java vs. C

I think Mr. Dew summed up C-style assertions quite eloquently. I only wish to add that they were much more important in C in the days before automated regression testing.
[ September 16, 2004: Message edited by: David Hibbs ]