Karlstad University Computer Science Design Contracts and Error Management External and internal errors and their contracts

Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 2 A system part exposes interfaces –External or internal External and Internal Interfaces System part Supplier Internal interface External interface

Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 3 Some possible sources of external errors External Interfaces Software Components The System Hardware Components Data Bases Error End Users Other System

Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 4 Some possible sources of internal errors Internal Interfaces Programmers Error Program Fault Violation Designers Error Design Fault Violation The system

Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 5 External errors –Committed by end users or external systems Databases, external components, hardware –Cause violation of external interfaces Internal errors –Committed by developers –Result in faults in the software –Cause violation of internal interfaces External and Internal Errors On a permanent basis, consistent until the software is corrected On a per use basis, varying from case to case

Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 6 External errors –Correct input cannot be assured –wrong input should be handled and the user informed –Best managed by weak contracts Internal errors –Correct input can be assured –System faults should be detected And corrected by the responsible author –Best managed by strong contracts Correspondence Contracts  Errors

Karlstad University Computer Science Design Contracts and Error Management What happens if the precondition is not satisfied? Can we support internal error detection?

Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 8 Different Strategies for Handling Violated Preconditions Since the client has not kept its part of the contract, the supplier has no obligations whatsoever The supplier can do whatever it wants Two possible strategies –Do nothing special try to perform the task in the normal way hope that the system will die :-) –Trap the violation and make the system die exit (or throw an undocumented runtime exception) possibly dump an error code to a log file

Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 9 An Example of Handling Precondition Violations getElement method in a list –The precondition states that position should be within the boundaries of the list size. –If the position is not ok, the system will still survive as long as position is within the array boundaries. –One approach is to trap the violation and make the system die to notify the developer to correct the error in the client code // Pre: 0 <= position < size() // Post: result = the element at position // ’position’ Object getElement(int position) { if(Compilation.ASSERT_IS_ON) Assert.isTrue(positionOK(position)); return elements[position]; }

Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 10 Do Not Try to Handle the Error Do not handle errors and allow the system to go on, this makes things worse –The client should not be aware of any exceptions that might be thrown. It could be tempted to catch it and thereby allow the error to live on. –Documenting an error exception that is not part of the contract would actually implement a different contract than the one specified for the method. What about making it part of the contract? Trapping the violation - The client is not aware of the test –From the client’s point of view, there is no test of the precondition. –The test can be removed without affecting the contract since it is not part of the contract For the client, there is no recovery from the error –The only measure taken if the precondition is violated is to exit the system. –It is an error trap, not an error handling mechanism.

Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 11 Rules for Precondition Violation Traps The trap should be completely transparent to the client –No return value to test or exception to catch –A trap causes the program to die when it detects an error The programmer should develop the client code without resorting to the traps –The traps may be disabled or enabled without his knowledge The supplier code should produce the same result with a trap as without it –The program may be run with traps enabled or disabled –The trap should not affect the behavior of the system in any way –In particular, the trap should not have any effect on the state.