Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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;
}
share|improve this question

marked as duplicate by gnat, BЈовић, GlenH7, Rein Henrichs, Kilian Foth May 3 '13 at 8:26

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1  
@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 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 2 '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 3 '13 at 11:00
add comment

2 Answers 2

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

share|improve this answer
    
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: devlicio.us/blogs/billy_mccafferty/archive/2006/09/22/…. 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 2 '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 3 '13 at 3:10
    
Could you see my edit? And I'm sorry for dragging this, but I really would like to figure this out –  EdvRusj May 3 '13 at 10:57
add comment

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

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.