Javalobby

He is a entrepreneur and a software architect from Tel Aviv, Israel. He is also a technology freak with about 20 years experience working with computers. He is currently working on his first private initiative in the area of software development tools. His vision is to maximize the abilities of software developers by providing pragmatic tools that enable them to get fast results. Zviki has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Using Java Assertions? Use an Assertion-failed Breakpoint!

05.07.2009
| 20929 views |
  • submit to reddit

I'm a big fan of assertions. I use them very often in my code as safeguards. I was very pleased when true, native assertions were introduced to Java: they allow adding more tests while keeping the code running faster when disabled. 

If you like assertions, you will appreciate the following tip. A failed assertion will throw a java.lang.AssertionError runtime exception. Logging the assertion failures is up to the application code. If your code does not report this error properly, you may completely miss the assertion failures. 

Eclipse has a very useful mechanism for breaking on Exceptions. It's a different kind of breakpoint, which is triggered when the exception is thrown, regardless of how (and if) it is caught. If you are using assertions, I highly recommend setting a breakpoint on assertion failures when debugging your code. Here's how:

 

  1. From the Run menu, select Add Java Exception Breakpoint...
  2. Type java.lang.AssertionError in the dialog box, select the exception and click OK.

That's it, you are done. From now on, the debugger will stop whenever an exception is throw. The breakpoint will appear in the breakpoints view. You can right click it and select Breakpoint Properties... to see all the settings you can control.

Eclipse-exception-breakpoint The most useful feature would be to break on uncaught exceptions only, although, in case of assertions, I would break in any case.
Needless to say, the exception breakpoints can be used for any kind of exception. Truly a hidden treasure worth adding to your toolbox. From http://blog.zvikico.com
Published at DZone with permission of its author, Zviki Cohen.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Mladen Girazovski replied on Thu, 2009/05/07 - 6:09am

Could you please give an example of the usage of assert that doesn't violate the rules in your first link?

 

There are also a few situations where you should not use them:

  • Do not use assertions for argument checking in public methods.

    Argument checking is typically part of the published specifications (or contract) of a method, and these specifications must be obeyed whether assertions are enabled or disabled. Another problem with using assertions for argument checking is that erroneous arguments should result in an appropriate runtime exception (such as IllegalArgumentException, IndexOutOfBoundsException, or NullPointerException). An assertion failure will not throw an appropriate exception.

  • Do not use assertions to do any work that your application requires for correct operation.

    Because assertions may be disabled, programs must not assume that the boolean expression contained in an assertion will be evaluated. Violating this rule has dire consequences. For example, suppose you wanted to remove all of the null elements from a list names, and knew that the list contained one or more nulls. It would be wrong to do this: 

        // Broken! - action is contained in assertion
        assert names.remove(null);
    The program would work fine when asserts were enabled, but would fail when they were disabled, as it would no longer remove the null elements from the list. The correct idiom is to perform the action before the assertion and then assert that the action succeeded: 
        // Fixed - action precedes assertion
        boolean nullsRemoved = names.remove(null);
        assert nullsRemoved;  // Runs whether or not asserts are enabled
    As a rule, the expressions contained in assertions should be free of side effects: evaluating the expression should not affect any state that is visible after the evaluation is complete. One exception to this rule is that assertions can modify state that is used only from within other assertions. An idiom that makes use of this exception is presented later in this document.

 

Zviki Cohen replied on Thu, 2009/05/07 - 8:57am

Using assertions to validate input is a common practice. The first bullet says that you shouldn't use them for public methods - since checking the arguments is not a debug-only logic. You can use it for your own internal methods (private methods).

 

Michael Lockhart replied on Mon, 2009/05/11 - 5:06pm

Awesome tip Zviki!   I'm actually motivated to try out assertions now, thanks.

So that the NetBeans crowd don't miss out:  from the Debug menu, choose New Breakpoint.  Select the Java Debugger and in the Breakpoint Type, choose Exception. NetBeans offers similar breakpoint options to Eclipse, and you can also filter on the throwing class.

Mike P(Okidoky) replied on Mon, 2009/05/11 - 6:23pm

Assertions are great. I also use them for logging. A startup configuration file would determine which packages get assertions enabled.

assert Log.println("hello " + heavyMethod());

With assertions off for this class, it'll bypass the heavyMethod() call.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
"Starting from scratch" is seductive but disease ridden
-Pithy Advice for Programmers