CSC/ECE 517 Fall 2010/ch6 6b HA

Assertions in Object Oriented Language

In most of the programming languages assertions are statements that enables developers to test assumptions about the code they write. For example, if a developer writes a function that checks if two strings are equal or not, he might assert that the lengths of the strings are equal. Assertions are always made using a Boolean expression which a developer assumes will be true when the assertion gets executed. If the assertion is false then error will be thrown at the runtime.

Introduction

By doing this verification on that Boolean expression, assertion confirms developer’s assumptions about the program behavior and hence increase the confidence that an application is as per the requirement and free of errors. Research has shown that by writing assertions while a developer is programming is one of the efficient ways to detect and fix bugs. Also, assertions acts as a documentation to the inner working of the code and hence improves the maintainability of the code which is an important aspect of software engineering.

While debugging code, developers can write assertions in two forms, simplest being –

assert expression1 ;

where the expression1 is a Boolean expression which if true, verifies the correctness of your code and if false, throws an error during runtime showing you the assertion without giving you any details about the error.

Second form of assertion is

assert expression1 : expression2

where expression1 is again a Boolean expression and expression2 is an expression that has some value. The value can be the error message or may be related to the some value related to the current code execution. By doing this a developer can know much more details about the error which is causing that assertion failure and allow them to diagnose and fix it. This form of assertion is usually used when a developer is not testing the app as it gives some additional information to the 3rd party developers/testers that might help them diagnose and fix the problem.

As stated above assertions help in verifying the correctness of a program. However, assertions should be carefully used as in some cases it can be expensive to evaluate the Boolean expression of an assertion. For example, if a developer is writing a program for binary search, then he may need to verify that the list should be sorted. Now if he uses some method in assertions for doing that, it can affect the performance of the app. For this reasons, almost every compiler supports enabling and disabling of assertions so that the developers don’t need to remove their code for assertions everywhere and to increase the performance and quality of the software.

Types of assertions

There are primarily three types of assertions in programming languages namely -

1) Preconditions: In such type of assertion, certain conditions should have been met before calling a method. These conditions are usually checked at the entry point of the calling function.

2) Postconditions: It defines the functionality of the method. By asserting post condtions at the end of the method developers check the output with the desired requirements

3) Invariants: These assertions define conditions over a specified region of the code and verifies state-space consistency for a class. It can be evaluated at the entry or exit points of the method.

Design by contract

Design by contract or Programming by Contract is a design approach for client and suppliers developing a computer software. According to this approach, software designers (or clients) define verifiable interface specifications for software modules with preconditions, post conditions and invariants. These specifications for software modules are known as contracts. A software designer should specify the pre and post conditions i.e before the execution what conditions should be true and after the execution what things should be true. In object oriented architecture, preconditions can be weakened by subclasses and post conditions can be strengthened.

As an example, if a function has some specified pre condition then client would held responsible if the condition fails inside the function. It also means that the function should not have to test for that precondition and similarly client should not have to write try/catch while calling that function. Client or a software designer should ensure that they will meet the pre-condition by doing runtime tests or may be by assuming some condition which will be satisfied based on the function requirements and specifications.

This explicit definition of pre and post conditions forces software designers to think about the requirements of the specification and their implementation. Also for developers, these assertions may also influence declaration and throwing of runtime exceptions and try/catch block. The design by contract approach eliminates unnecessary redundant checks. Pre and post conditions reduce the need for checking the need for verifying the same condition both at client as well as developer’s side.

For example if a method has specified some pre-condition then the failure of that condition is the responsibility of the client of the method. The method should not have to declare a checked exception for that condition, it should not have to test and throw for that condition, and likewise the client should not have to try/catch for that condition.