SlideServe
Menu
Préférences
© SlideServe · v2026

CSE 143

ryo avatar
13 diapositives · 345 Views · Sep 22, 2014

CSE 143. Error Handling [Section 2.8]. Error Handling. Need good documentation about module behavior and expectations Helps with understanding program Helps with debugging and maintenance. Assertions. An assertion describes an assumption about the current state of a program, typically:

CSE 143 - slide 1
01 / 13CSE 143
1 / 17

Télécharger la présentation

CSE 143
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation
  1. CSE 143 Error Handling [Section 2.8]

  2. Error Handling Need good documentation about module behavior and expectations • Helps with understanding program • Helps with debugging and maintenance

  3. Assertions • An assertion describes an assumption about the current state of a program, typically: • At function entry and exit • At the beginning of each loop iteration • Two styles of assertions • In executable statements • Comments • Help to reason about program and provide error-checking at runtime

  4. Preconditions and Postconditions • Precondition: A condition assumed true at the time a function is invoked • Postcondition: A condition guaranteed true at the time a function returns • Example: sqrt(double x) function • precondition: x >= 0 • postcondition: returns r such that r*r is equal to x

  5. Checking Preconditions Who is responsible for checking preconditions? • Example: Average a list of numbers double Average(int nums[], int len); // PRE: len > 0 // POST: Returns average of // nums[0]..nums[len-1] • What happens if len <= 0?

  6. Option 1: Assume input OK // PRE: len > 0 // POST: Returns average of // nums[0]..nums[len-1] double Average(int nums[], int len) { • int sum = 0; • for (int j = 0; j < len; j++) sum = sum + nums[j]; • return ((double) sum / (double) len); }

  7. Option 2: Return Safe Value • If input bad, return a “safe” value • Actually modifying spec to include bad inputs double Average(int nums[], int len) { if (len <= 0) return 0; // 0 is “safe” • int sum = 0; • for (int j = 0; j < len; j++) sum = sum + nums[j]; • return ((double) sum / (double) len); }

  8. Option 3: Check and Exit #include <stdlib.h> #include <iostream.h> double Average(int nums[], int len) { if (len <= 0) { cerr << “Average: len <= 0” << endl; exit(1); // exit with error status } int sum = 0; for (int j=0; j<len; j++) sum = sum + nums[j]; return ((double) sum / (double) len); }

  9. Option 4: assert macro #include <assert.h> double Average(int nums[], int len) { assert(len > 0); int sum = 0; for (int j = 0; j < len; j++) sum = sum + nums[j]; • return ((double) sum / (double) len); } • If an error occurs, program exits, printing: • Assertion failed: len > 0 • file main.cpp, line 23 • Can turn off assertions once code is debugged • Put #define NDEBUG before #include <assert.h>

  10. Option 5: Status Flag double Average(int nums[], int len, bool &error) { if (len <= 0) { error = true; return 0; } error = false; int sum = 0; for (int j = 0; j < len; j++) sum = sum + nums[j]; return ((double) sum / (double) len) } • Client must test for an error after a call

  11. Option 6: Exceptions • Exceptions are an advanced technique for dealing with errors • Client doesn’t check for errors at each call, but writes a function that handles the error • Compiler determines when an exception should be raised • the error-handling function gets called automatically • Exceptions are found in many other programming languages • heavily used in Java • Won't be taught in 143

  12. Error Handling Summary • Assertions are useful for making explicit any assumptions made in code • Assertions can be in comments or code • Use assert macro from #include <assert.h> for explicit checking • Use comments in .h file to help clients do the right thing • We looked at 6 techniques for checking preconditions • similar techniques can be used for other types of error handling • Explicit error-checking can be cumbersome • But if you leave it out, you have to trust callers...

  13. Use assert() to aid debugging • Use assert liberally in the programming projects • Test preconditions especially, in as much detail as practical • Test invariants and postconditions when reasonable • But asserts don't substitute for user-visible error handling! • Don't worry too much about the overhead • Think of your programs as still in debug mode, even when turned in. • It is possible to disable assertion checking in "production" code.