Amit asks: "is this is the only reason for using asserstion... as we can always use exception handling.. ?"
Pretty much, yes. But the benefit is huge. Think of assertions an an exception mechanism that can be disabled in the field. You can always do this in every method:
That will work, but look at the overhead. The only way to disable the mechanism in the field (where your customers figure they paid for the software, so there better not be any pre- or postcondition violations) is to edit out all the checks and throws. Then you have to redo your method declarations, because they no longer throw AssertionError. Then you have to recompile your code, and run your regression tests again.
It's really about economics. One economy is the processor-cycle economy. That's the one we pregrammers tend to focus on, especially when preparing for the
SCJP exam. In my own code, the pre- and postcondition checks usually don't take long to run, but now and then they do. With the assertion mechanism, those checks (corresponding to preconditionViolation() and postconditionViolation() above) never happen in the field.
The other economy is the development cost economy. In a big company, the big boss would prefer not to pay someone to delete all those condition checks, and someone else to run the tests. In a small company like my own (it couldn't possibly be smaller, if you get my drift), I would rather go out dancing or work on my next novel than stay up late doing all that engineering.