Exception Vs Assertion

Question

What is difference between java Exception handling and assert any condition?

its know that assert is of two type.but when should we use assert keyword?

Answer 1

Use assertions for internal logic checks within your code, and normal exceptions for error conditions outside your immediate code's control.

Don't forget that assertions can be turned on and off - if you care about things like argument validation, that should be explicit using exceptions. (You could, however, choose to perform argument validation on private methods using assertions, on the grounds that a violation at that point is due to an internal bug rather than an external error.)

Alternatively it's entire reasonable (IMO) to use exceptions for everything. I personally don't use assertions much at all, but it's a matter of personal preference to some extent. (There can certainly be objective arguments for and against assertions, but it's not sufficiently clear cut to remove preference altogether.)

Answer 2

Assert is for debugging purpose only and its trigger condition should not happen (null pointer when there shouldn't be, etc.)

Exception is for special system events that may always happen : FileNotFound, ConnectionToServerLost, etc.

Answer 3

Exception is a mechanism of checking if the implementation is executing without any expected or unexpected errors or not. So, we see that exceptions are basically used for handling even the unforseen conditions during the execution of an application in a better way and hence using exceptions effectively results into a robust application.

Assertions should never be a part of the implementation of some functionality of the application. They should only be used to verify the assumptions - just to be sure that whatever we assumed while desinging the solution is actually valid in practical as well.

reference: http://geekexplains.blogspot.com/2008/06/asserions-in-java-assertions-vs.html

Answer 4

Java assertions are built on top of Java exceptions and exception handling. Indeed, when a Java assertion fails, the result is an AssertionError exception that can be caught like any other Java exception. The key differences between exceptions and assertions are:

• Assertions are intended to be used solely as a means of detecting programming errors, aka bugs. By contrast, an exception can indicate other kinds of error or "exceptional" condition; e.g. invalid user input, missing files, heap full and so on.
• The Java language provides syntactic support for assertions, in the form of the assert statement. Compare the following:

    if (x != y) {
         throw new SomeException("x != y");
    }

    assert x != y;

• Most importantly, Java allows you to enable or disable assertion checking globally or on individual classes when you start the JVM.

Note: some people say that you should always run production code with assertion checking turned off. I tend to disagree with this as a blanket statement. If your production code is known to be stable AND you need to squeeze that last bit of performance out of it, then turning off assertions is good. But, if a (say) 10% performance hit is not a real problem, I'd prefer to have an application die with an assertion error if the alternative is continue and corrupt my database.

EDIT: @Mario Ortegón commented thus:

The "turning off" is because assertions can be used to verify the result of an optimized algorithm by comparing its implementation against a well-known, but slow, algorithm. So, in development it is OK to invoke that O(N^3) method to assert that the O(log N) algorithm works as intended. But this is something that you do not want in production.

Whether or not you think it is good practice to turn off assertions in production, it is definitely bad practice to write assertions that have a significant impact on performance when enabled. Why? Because it means that you no longer have the option of enabling assertions in production (to trace a problem) or in your stress / capacity testing. In my opinion, if you need to do O(N^3) pre/post-condition testing, you should do it in your unit tests.