Limitations of Assertion in Java

Assertions: It give you a way to test your assumptions during development and debugging. They are typically enabled during testing but disabled during deployment.

private void numberTest(int num){
    if(num>=0){
   useNumber(num+a);
}else{  // Here it will come only if num<0
       System.out.println("This is a negative number:"+num);
}


}


use assert : Suppose number will always be positive,
private void numberTest(int num){
    assert(num>=0);         // First flavor of assertion
useNumber(num+a);       

}



assert(num>=0):"This is negative number"+num;         // second flavor of assertion
    exp1                    exp2

Here this line has tqo expression, exp2 will execute if number is negative and it will print this String message following AssertionError


Limitations 

1) Don't Use Assertions to Validate Arguments to a Public Method

   The following is an inappropriate use of assertions:
   public void assertionTest(int x) {
       assert (x > 0);                  // inappropriate use of assertion but legal!
       // do things with x, may be some more code using x
   }

Explanation: A public method might be called from code that you don't control (or from code you have never seen). Because public methods are part of your interface to the outside world, you're supposed to guarantee that any constraints on the arguments will be enforced by the method itself. But since assertions aren't guaranteed to actually run (they're typically disabled in a deployed application), the enforcement won't happen if assertions aren't enabled. You don't want publicly accessible code that works only conditionally, depending on whether assertions are enabled.

Solution: If you need to validate public method arguments, you'll probably use exceptions to throw, like , an IllegalArgumentException if the values passed to the public method are invalid.

2) Do Use Assertions to Validate Arguments to a Private Method

     If you write a private method, you almost certainly wrote (or control) any code that calls it. When you
     assume that the logic in code calling your private method is correct, you can test that assumption with an
     assertion as follows:

private void testAssert(int x) {
         assert (x > 0);
           // do things with x
     }

3) Don't Use Assertions to Validate Command-Line Arguments
   Reason: Please see the explanation of first point, that is also applicanle here.

4) Do use Assertions, even in public methods, to test for cases where you know those will never, ever supposed to execute

    This can include code blocks that should never be reached, including the default of a switch statement as follows:

     switch(x) {
        case 1: a = 5; break;
        case 2: a = 6; break;
        case 3: a = 102; break;
        default: assert false; // we're never supposed to get here!
     }

Explanation: If you assume that a particular code block won't be reached, as in the preceding example where you assert that variable 'x' must be either 1, 2, or 3, then you can use assert false to cause an AssertionError to be thrown immediately if you ever do reach that code.

5) Don't Use Assert Expressions that Can Cause Side Effects!

   The following would be a very bad idea:

   public void testAssertion() {
      assert (otherMethod());
      // continues on
   }
   public boolean otherMethod() {
      i = j--;
      return true;
   }

 Explanation: The rule is, an assert expression should leave the program in the same state it was in before the expression! Assert expressions aren't guaranteed to always run, so you don't want your code to behave differently like depending on whether assertions are enabled. It means assertions must not cause any side effects. If assertions are enabled, the only change to the way your program runs is that an AssertionError can be thrown if one of your assertions (think: assumptions) turns out to be false.