CS 261 – Data Structures Preconditions, Postconditions & Assert.

Slides:



Advertisements
Similar presentations
Chapter 17 Failures and exceptions. This chapter discusses n Failure. n The meaning of system failure. n Causes of failure. n Handling failure. n Exception.
Advertisements

Copyright W. Howden1 Programming by Contract CSE 111 6/4/2014.
De necessariis pre condiciones consequentia sine machina P. Consobrinus, R. Consobrinus M. Aquilifer, F. Oratio.
Detecting Bugs Using Assertions Ben Scribner. Defining the Problem  Bugs exist  Unexpected errors happen Hardware failures Loss of data Data may exist.
1 CSE 403 Design by Contract Reading: Pragmatic Programmer Ch. 4, Object-Oriented Design and Patterns, Ch. 3 (Horstmann) These lecture slides are copyright.
Code Documentation. Important!  It’s for you  It’s for others.
C++ Programming: Program Design Including Data Structures, Fourth Edition Chapter 15: Exception Handling.
Chapter 16: Exception Handling C++ Programming: From Problem Analysis to Program Design, Fifth Edition.
Objectives In this chapter you will: Learn what an exception is Learn how to handle exceptions within a program See how a try / catch block is used to.
 Both System.out and System.err are streams—a sequence of bytes.  System.out (the standard output stream) displays output  System.err (the standard.
C++ Programming: From Problem Analysis to Program Design, Third Edition Chapter 16: Exception Handling.
CSCE 121: Introduction to Program Design and Concepts Dr. J. Michael Moore Spring 2015 Set 7: Errors 1 Based on slides created by Bjarne Stroustrup.
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
Chapter 8 Designing Classes. Assignment Chapter 9 Review Exercises (Written)  R8.1 – 8.3, 8.5 – 8.7, 8. 10, 8.11, 8.13, 8.15, 8.19, 8.20 Due Friday,
Object Oriented Design An object combines data and operations on that data (object is an instance of class) data: class variables operations: methods Three.
Debugging: Catching Bugs ( I ) Ying Wu Electrical & Computer Engineering Northwestern University ECE230 Lectures Series.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
Copyright W. Howden1 Lecture 13: Programming by Contract.
1 Specifying Object Interfaces. 2 Major tasks in this stage: --are there any missing attributes or operations? --how can we reduce coupling, make interface.
Software Testing and Quality Assurance
Static and Dynamic Contract Verifiers For Java Hongming Liu.
OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common behavior (operations and properties). (Abstract) types.
Page 1 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Chapter 6 Semantic Integrity in Component.
1 Advanced Material The following slides contain advanced material and are optional.
Eiffel Language and Design by Contract Contract –An agreement between the client and the supplier Characteristics –Expects some benefits and is prepared.
Fall 2007CS 225 Program Correctness and Efficiency Chapter 2.
Computer Science 340 Software Design & Testing Design By Contract.
PRAGMATIC PARANOIA Steven Hadfield & Anthony Rice.
Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Chair of Software Engineering Static program checking and verification Slides: Based.
Contract based programming Using pre- and post-conditions, and object invariants Contract based programming1.
Google C++ Testing Framework Death Tests. In many applications, there are assertions that can cause application failure if a condition is not met. ◦ Square.
How to Design Error Steady Code Ivaylo Bratoev Telerik Corporation
1 Debugging: Catching Bugs ( II ) Ying Wu Electrical Engineering & Computer Science Northwestern University EECS 230 Lectures.
Programming Life Cycle Problem analysisunderstand the problem Requirements definition specify what program will do High- and low-level designhow it meets.
CORRECTNESS CRITERIA FOR CONCURRENCY & PARALLELISM 6/16/2010 Correctness Criteria for Parallelism & Concurrency 1.
Today’s Agenda  Reminder: HW #1 Due next class  Quick Review  Input Space Partitioning Software Testing and Maintenance 1.
Reasoning about programs March CSE 403, Winter 2011, Brun.
Software Reliability. Risks of faulty software  Example: –Therak 25, –AT&T network failure –Airport traffic control  Costs of software errors can be.
Pre- and postconditions, Using assertions and exceptions 1 Pre- and postconditions Using assertions and exceptions.
Programming by Contract 2 Object-oriented languages Class Invariants.
(c) University of Washington13-1 CSC 143 Java Specifications: Programming by Contract Reading: Ch. 5.
Verificare şi Validarea Sistemelor Soft Tem ă Laborator 1 ESC/Java2 Extended Static Checker for Java Dat ă primire laborator: Lab 1 Dat ă predare laborator:
Chapter 15: Exception Handling C++ Programming: Program Design Including Data Structures, Fifth Edition.
SWE 4743 Abstract Data Types Richard Gesick. SWE Abstract Data Types Object-oriented design is based on the theory of abstract data types Domain.
Defensive Programming CNS 3370 Copyright 2003, Fresh Sources, Inc.
Programming & Debugging. Key Programming Issues Modularity Modifiability Ease of Use Fail-safe programming Style Debugging.
Chapter 2 Comments, Conditions, Assertions Comments Preconditions Postconditions Assertions.
Chapter 7 Programming by contract: preconditions and postconditions.
DBC NOTES. Design By Contract l A contract carries mutual obligations and benefits. l The client should only call a routine when the routine’s pre-condition.
Throw, Throws & Try-Catch Statements Explanations and Pictures from: Reference:
Testing It is much better to have a plan when testing your programs than it is to just randomly try values in a haphazard fashion. Testing Strategies:
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
CSE 374 Programming Concepts & Tools Hal Perkins Fall 2015 Lecture 17 – Specifications, error checking & assert.
Class Invariants Class invariants are logical conditions to ensure the correct working of a class. Class invariants must hold true when an object is created,
Chapter 6 CS 3370 – C++ Functions.
Logger, Assert and Invariants
Topics: jGRASP editor ideosyncrasies assert debugger.
CSE 374 Programming Concepts & Tools
CSE 143 Error Handling [Section 2.8] 3/30/98 CSE 143.
Specifications What? Not how!.
Preconditions, Postconditions & Assertions
Specifying Object Interfaces
CS 220: Discrete Structures and their Applications
CSC 143 Error Handling Kinds of errors: invalid input vs programming bugs How to handle: Bugs: use assert to trap during testing Bad data: should never.
Hoare-style program verification
Go to pollev.com/cse143.
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
CSE 1020:Software Development
Scratch Programming Lesson 7 Debugging.
Computer Science 340 Software Design & Testing
Presentation transcript:

CS 261 – Data Structures Preconditions, Postconditions & Assert

Preconditions /* pre: size < SIZELIMIT pre: name != null; post: result >= MINRESULT */ int magic (int size, char *name) { assert(size < SIZELIMIT); assert(name != null) … DO STUFF … assert(result >= MINRESULT); return result; } preconditions are input conditions for the function 1.magic is only required to do it’s task if pre-conditions are satisfied 2.The caller knows that if he satisfies those conditions, magic will perform the task correctly

Postconditions /* pre: size < SIZELIMIT pre: name != null; post: result >= MINRESULT */ int magic (int size, char *name) { assert(size < SIZELIMIT); assert(name != null) … DO STUFF … assert(result >= MINRESULT); return result; } postconditions are output conditions for a function 1.magic guarantees the condition will hold when it completes. As developer, you must ensure this! 2.The caller is certain of what it will get, provided it has met preconditions

Pre-conditions + Post-conditions When combined….they define a contract!!! Using pre and post conditions and CHECKING them helps you find and remove bugs and fulfill the contract! pre post

In practice…. put pre-conditions in the header put post-conditions in the header during debugging, use asserts() to enforce them To catch errors when recovery is generally not immediately possible Useful during debugging, but we should replace for “Release”

Bugs and Errors 1.Program Error: a bug, and should never occur 2.Run-time Error: can validly occur at any time during execution (e.g. user input is illegal) and should be recoverable Replace these asserts with a reasonable error message Write recovery code for these kinds of errors