Assertions vs Exceptions - is my understanding of the differences between the two correct?

Question

Design By Contract uses preconditions and postconditions of the public methods in a class together to form a contract between the class and its clients.

a) In code we implement preconditions and postconditions either as assertions or as exceptions?

b) We implement preconditions and postconditions in code as exceptions if not fulfilling preconditions or postconditions doesn't indicate logically impossible situations or programming errors?

c) we implement them in code as assertions when not fulfilling preconditions or postconditions does indicate logically impossible situations or programming errors?

d) Should preconditions and postconditions only be defined on public methods?

EDIT:

Aren't the following checks considered to be part of a normal operation ( and as I already mentioned, I've seen plenty of articles on DbC using similar examples for preconditions, where checks were made against arguments supplied by the user ), since if the user enters bad data, then without checks operation won't be rejected and as such system will stop working according to specs:

Link:

public User GetUserWithIdOf(int id,
        UserRepository userRepository) {
  // Pre-conditions
  if (userRepository == null)
      throw new ArgumentNullException(
          "userRepository");
  if (id <= 0)
      throw new ArgumentOutOfRangeException(
          "id must be > 0");

  User foundUser = userRepository.GetById(id);

  // Post-conditions
  if (foundUser == null)
      throw new KeyNotFoundException("No user with " +
          "an ID of " + id.ToString() +
          " could be located.");

  return foundUser;
}

@gnat: I don't agree that it is a duplicate, since I'm asking more to the effect what the definition of assertions is and whether pre and post conditions can be implemented as both assertions and exceptions. My question is a response to http://people.cs.aau.dk/~normark/oop-csharp/pdf/contracts.pdf claiming that class contract is the sum of the assertions in the class and that DbC represents the idea of designing and specifying programs by means of assertions, which would suggest that pre and post-conditions can only be implemented as assertions and not also as exceptions — EdvRusj, May 02 '13 at 21:00
@gnat: but I already explained how this question is different and anybody reading this topic ( including Stephen C ) can easily see why other answers do not address my questions. And if you can't see the difference in the original answer, then you surely must notice the difference in questions that follow the original — EdvRusj, May 03 '13 at 11:00

Stephen C · Answer 1 · 2013-05-02T23:13:28.453

a) In code we implement preconditions and postconditions either as assertions or as exceptions?

Strictly, no. The pre/postcondition is actually the test that raises the exception. The exception is merely the way of saying that pre/postcontion has been violated.

b) We implement preconditions and postconditions in code as exceptions if not fulfilling preconditions or postconditions doesn't indicate logically impossible situations or programming errors?

No. People often use explicit test / raise exception code to indicate a bug, etc.

c) we implement them in code as assertions when not fulfilling preconditions or postconditions does indicate logically impossible situations or programming errors?

You can do. But see above.

d) Should preconditions and postconditions only be defined on public methods?

No. If you are using them (formally) there is no reason to restrict them to public methods.

Actually, the key difference between the two approaches is that you can (typically) turn off checking of the "assertion" style of pre/postconditions (e.g. Java's assert statements) when you move your code into production. In the case of Java, this is typically done using a JVM command line option.

This means that you shouldn't use assertion style pre/postconditions for checks that are part of "normal operation" ... like validating user input. In fact, you probably shouldn't treat them as pre/postconditions at all. They are part of the program's active functionality (for the lack of a better way of describing it ...)

This is confusing. I've seen plenty articles using examples where pre post-conditions were used for checks that are part of a normal operation. Here's one such link: http://devlicio.us/blogs/billy_mccafferty/archive/2006/09/22/Design_2D00_by_2D00_Contract_3A00_-A-Practical-Introduction.aspx. I've also read that DbC uses preconditions in public contract of method, and argument checking in public contracts IS part of a normal operation — EdvRusj, May 02 '13 at 23:36
@EdvRusj - perhaps you are misunderstanding what I mean by part of normal operation. I mean checks that should never, ever under any circumstances be disabled. Like if you did disable them, the system stops working according to its spec. Like when the user enters bad data it is not rejected. By contrast, if you disabled pre/postcondition checking then the system works ... modulo that it behaves differently if a Bug happens. — Stephen C, May 03 '13 at 03:10
Could you see my edit? And I'm sorry for dragging this, but I really would like to figure this out — EdvRusj, May 03 '13 at 10:57

score 0 · Answer 2 · edited May 02 '13 at 23:09

You should define them as assumptions, (in debugging as assertions) so if the pre or post condition isn't true then you have an logical error in in your program.

The key point here is avoiding the test in production code to speed it up,

for example a binary search can go in O(log n) time only if the array is already sorted (precondition) but testing this (for the exception) takes O(n) so if you test for that you might as well go for the linear search and get an early return out of it.

They can be defined on any piece of code (i.e. anything that can be extracted into a method).

Assertions vs Exceptions - is my understanding of the differences between the two correct?

2 Answers2