Exception VS Assertion

Exception Vs Assertion

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.)

When to use an assertion and when to use an exception

Assertions should be used to check something that should never happen, while an exception should be used to check something that might happen.

For example, a function might divide by 0, so an exception should be used, but an assertion could be used to check that the harddrive suddenly disappears.

An assertion would stop the program from running, but an exception would let the program continue running.

Note that if(group != null) is not an assertion, that is just a conditional.

Assert vs Exceptions

I see two use cases for assertions in production code:

At the beginning of a method you would normaly check if the given parameter are valid. For public methods you would use if statments and exceptions. For private methods you would make the simelar checks using assert. The idea is to avoid redundant checks in produktion while in testing (or when somesting goes wrong) you can just activate assertions to do some double checking.

The other reason to use assertions is to document the assumptions that are used in the following code. Like that some value is considered never to be null here.

Here some example code

public class Exampel {
public publicMethod(final Integer i) {
if (i == null) {
throw new RuntimeException("i should not be null");
}

privateMethod(i):
}

private privateMethod(final Integer i) {
assert i != null;

// do something
}
}

You would not want to check i for null several times. You would just assume that privateMethodis used correctly. You also give anyone that reads your code the hint that passing null to privateMethodis the wrong thing to do.

Assertion VS Runtime exception

Assertions are usually a development technique that can be switched off in production. That's true in Java, Eiffel, C++, and every language that I know that uses them.

Personally I prefer runtime exceptions to enforce the contract. You can't turn those off.

Debug.Assert vs Exception Throwing

Though I agree that your reasoning is plausible -- that is, if an assertion is violated unexpectedly, it makes sense to halt execution by throwing -- I personally would not use exceptions in the place of assertions. Here's why:

As others have said, assertions should document situations that are impossible, in such a manner that if the allegedly impossible situation comes to pass, the developer is informed. Exceptions, by contrast, provide a control flow mechanism for exceptional, unlikely, or erroneous situations, but not impossible situations. For me, the key difference is this:

  • It should ALWAYS be possible to produce a test case which exercises a given throw statement. If it is not possible to produce such a test case then you have a code path in your program which never executes, and it should be removed as dead code.

  • It should NEVER be possible to produce a test case which causes an assertion to fire. If an assertion fires, either the code is wrong or the assertion is wrong; either way, something needs to change in the code.

That's why I would not replace an assertion with an exception. If the assertion cannot actually fire, then replacing it with an exception means you have an untestable code path in your program. I dislike untestable code paths.

Do we have to write unit-test for assertion or exception?

Your question cannot be answered in a generic manner.

Perfect unit testing is impossible, even "very good" unit testing is incredibly hard, and is possible only when testing "very good" code. Be careful to not fall into this trap, all depends on your quality requirements.

Do you develop a mission critical system when a failure can cost lives? Go an extra mile and test as much as possible. Any change will have to pass lots of bureaucratic steps anyway. Otherwise adapt to your requirements. One of the main benefits of automated testing is simplified refactoring, when you can change (sometimes significantly) your implementation and still be sure it works to some extend. Too much testing and this gun points at you cos any change will require lots of changes in tests eventually blocking your progress.

No silver bullet as usual



Related Topics



Leave a reply



Submit