0

What are the benefits of Assert statement really. I don't get why do I need to use it. I read nearly 100 questions/answers about assert statement but still no idea about what are the benefits of it. There are too many conflicts about this statement I think.

For example some people says "Never use it in production" but some people says "You can use them in production level". Some people says "Always handle assertionErrors in production" but some people says "Never and ever handle assertionErrors either in production or development level".

Why this is an incorrect usage for example https://stackoverflow.com/a/2758262/1379734

Community
  • 1
  • 1
hellzone
  • 5,393
  • 25
  • 82
  • 148
  • 3
    Your question is a matter of opinion; I believe it is off-topic here. – Basile Starynkevitch Oct 31 '13 at 16:20
  • 1
    possible duplicate of [Assertion in Java?](http://stackoverflow.com/questions/2758224/assertion-in-java) – Luiggi Mendoza Oct 31 '13 at 16:21
  • 4
    What you are seeing is called **"a difference of opinion"**. You need to read the arguments and make up your own mind which one(s) you agree with. Rehashing the opinions all over again is not going to be fruitful. – Stephen C Oct 31 '13 at 16:24

3 Answers3

1

Why would this be considered incorrect?

public int pop() {
   // precondition
   assert !isEmpty() : "Stack is empty";
   return stack[--num];
}

The assert is supposed to express an invariant condition. If pop() were a private method, then you could expect that it should only ever be called by code that checks for an empty stack. Because this method is public, you have no control over what assumptions can be enforced in the caller. In this case, a stack underflow should result in an Exception.

Again, assert is a declaration of something that must be true, not something that may be true. "May" conditions should be enforced through other run-time checking and not declared in asserts.

Whether or not to enable assertions in production is subject to preferences. The argument for doing so is that asserts should never fail, so they should be safe in production. The arguments against doing so are the performance penalty (some assert conditions can be expensive to calculate), and the disruptive nature of throwing Error throwables.

Charles Forsythe
  • 1,831
  • 11
  • 12
0

You appear to be look for simple it is always a great idea or it's never a great idea. This is not the case. It has use cases where it makes sense and in limited case you want to avoid them for performance but this is very rare.

Some people don't know any more about assertions than you do, but are happy to voice an opinion. I suggest you come to your own conclusions and use it where it is right for you.

On the subject of Errors and Exceptions, I suggest only handling these where

  • you can take some corrective action
  • you need to log the error so a human can see it has happened and take action.

For this reason I trap Throwable at the highest level of my thread(just before it dies) and make sure it is logged correctly. In all other cases, I only trap the exceptions I can do something useful with.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
0

Asserts require overhead to process. Theoretically, if they pass in testing, there's no reason to re-run them in production. It's possible that your testing is incomplete, and an assert might catch an unexpected condition not addressed during testing, but the hope is that the logs will let you figure out what went wrong, without the need of running the asserts.

sdanzig
  • 4,510
  • 1
  • 23
  • 27