n Maurice Wilkes, 1949 n Organize software to minimize errors. n Eliminate most of the errors we made anyway.

Transcription

1 Bjare Stroustrup Chapter 5 Errors Abstract Whe we program, we have to deal with errors. Our most basic aim is correctess, but we must deal with icomplete problem specificatios, icomplete programs, ad our ow errors. Here, we ll cocetrate o a key area: how to deal with uexpected fuctio argumets. We ll also discuss techiques for fidig errors i programs: debuggig ad testig. 2 Kids of errors Argumet checkig Error reportig Error detectio Exceptios Debuggig Testig Overview Errors I realized that from ow o a large part of my life would be spet fidig ad correctig my ow mistakes. Maurice Wilkes, 1949 Whe we write programs, errors are atural ad uavoidable; the questio is, how do we deal with them? Orgaize software to miimize errors. Elimiate most of the errors we made ayway. Debuggig Testig Make sure the remaiig errors are ot serious. My guess is that avoidig, fidig, ad correctig errors is 95% or more of the effort for serious software developmet. You ca do much better for small programs. or worse, if you re sloppy 3 4 1

2 Your Program 1. Should produce the desired results for all legal iputs 2. Should give reasoable error messages for illegal iputs 3. Need ot worry about misbehavig hardware 4. Need ot worry about misbehavig system software 5. Is allowed to termiate after fidig a error 3, 4, ad 5 are true for begier s code; ofte, we have to worry about those i real software. Sources of errors Poor specificatio What s this supposed to do? Icomplete programs but I ll ot get aroud to doig that util tomorrow Uexpected argumets but sqrt() is t supposed to be called with -1 as its argumet Uexpected iput but the user was supposed to iput a iteger Code that simply does t do what it was supposed to do so fix it! 5 6 Kids of Errors Check your iputs Compile-time errors Sytax errors Type errors Warigs Lik-time errors Ru-time errors Detected by computer (crash) Detected by library (exceptios) Detected by user code Logic errors Detected by programmer (code rus, but produces icorrect output) Before tryig to use a iput value, check that it meets your expectatios/requiremets Fuctio argumets Data from iput (istream) 7 8 2

3 Bad fuctio argumets The compiler helps: Number ad types of argumets must match it area(it legth, it width) retur legth*width; it x1 = area(7); // error: wrog umber of argumets it x2 = area("seve", 2); // error: 1 st argumet has a wrog type it x3 = area(7, 10); // ok it x5 = area(7.5, 10); // ok, but dagerous: 7.5 trucated to 7; // most compilers will war you it x = area(10, -7); // this is a difficult case: // the types are correct, // but the values make o sese Bad Fuctio Argumets So, how about it x = area(10, -7);? Alteratives Just do t do that Rarely a satisfactory aswer The caller should check Hard to do systematically The fuctio should check Retur a error value (ot geeral, problematic) Set a error status idicator (ot geeral, problematic do t do this) Throw a exceptio Note: sometimes we ca t chage a fuctio that hadles errors i a way we do ot like Someoe else wrote it ad we ca t or do t wat to chage their code 9 10 Why worry? Bad fuctio argumets You wat your programs to be correct Typically the writer of a fuctio has o cotrol over how it is called Writig do it this way i the maual (or i commets) is o solutio may people do t read mauals The begiig of a fuctio is ofte a good place to check Before the computatio gets complicated Whe to worry? If it does t make sese to test every fuctio, test some How to report a error Retur a error value (ot geeral, problematic) it area(it legth, it width) // retur a egative value for bad iput if(legth <=0 width <= 0) retur -1; retur legth*width; So, let the caller beware it z = area(x,y); if (z<0) error("bad area computatio"); // 11 Problems What if I forget to check that retur value? For some fuctios there is t a bad value to retur (e.g., max()) 12 3

4 How to report a error Set a error status idicator (ot geeral, problematic, do t!) it erro = 0; // used to idicate errors it area(it legth, it width) if (legth<=0 width<=0) erro = 7; // meas or retur legth*width; So, let the caller check it z = area(x,y); if (erro==7) error("bad area computatio"); // Problems What if I forget to check erro? How do I pick a value for erro that s differet from all others? How do I deal with that error? 13 How to report a error Report a error by throwig a exceptio class Bad_area ; // a class is a user defied type // Bad_area is a type to be used as a exceptio it area(it legth, it width) if (legth<=0 width<=0) throw Bad_area; retur legth*width; // ote the a value Catch ad deal with the error (e.g., i mai()) try it z = area(x,y); // if area() does t throw a exceptio // make the assigmet ad proceed catch(bad_area) // if area() throws Bad_area, respod cerr << "oops! Bad area calculatio fix program\"; 14 Exceptios Out of rage Exceptio hadlig is geeral You ca t forget about a exceptio: the program will termiate if someoe does t hadle it (usig a try catch) Just about every kid of error ca be reported usig exceptios You still have to figure out what to do about a exceptio (every exceptio throw i your program) Error hadlig is ever really simple Try this vector<it> v(10); // a vector of 10 its, // each iitialized to the default value, 0, // referred to as v[0].. v[9] // set values for (it i = 0; i<v.size(); ++i) v[i] = i; for (it i = 0; i<=10; ++i) // prit 10 values (???) cout << "v[" << i << "] == " << v[i] << edl; vector s operator[ ] (subscript operator) reports a bad idex (its argumet) by throwig a Rage_error if you use #iclude "std_lib_facilities.h" The default behavior ca differ You ca t make this mistake with a rage-for

5 Exceptios for ow For ow, just use exceptios to termiate programs gracefully, like this it mai() try // catch (out_of_rage&) // out_of_rage exceptios cerr << "oops some vector idex out of rage\"; catch ( ) // all other exceptios cerr << "oops some exceptio\"; A fuctio error() Here is a simple error() fuctio as provided i std_lib_facilities.h This allows you to prit a error message by callig error() It works by disguisig throws, like this: void error(strig s) // oe error strig throw rutime_error(s); void error(strig s1, strig s2) // two error strigs error(s1 + s2); // cocateates Usig error( ) How to look for errors Example cout << "please eter iteger i rage [1..10]\"; it x = -1; // iitialize with uacceptable value (if possible) ci >> x; if (!ci) // check that ci read a iteger error("did t get a value"); if (x < 1 10 < x) // check if value is out of rage error("x is out of rage"); // if we get this far, we ca use x with cofidece Whe you have writte (drafted?) a program, it ll have errors (commoly called bugs ) It ll do somethig, but ot what you expected How do you fid out what it actually does? How do you correct it? This process is usually called debuggig

6 Debuggig How ot to do it while (program does t appear to work) // pseudo code Radomly look at the program for somethig that looks odd Chage it to look better Key questio How would I kow if the program actually worked correctly? Program structure Make the program easy to read so that you have a chace of spottig the bugs Commet Explai desig ideas Use meaigful ames Idet Use a cosistet layout Your IDE tries to help (but it ca t do everythig) You are the oe resposible Break code ito small fuctios Try to avoid fuctios loger tha a page Avoid complicated code sequeces Try to avoid ested loops, ested if-statemets, etc. (But, obviously, you sometimes eed those) Use library facilities First get the program to compile Is every strig literal termiated? cout << "Hello, << ame << '\'; // oops! Is every character literal termiated? cout << "Hello, " << ame << '\; // oops! Is every block termiated? if (a>0) /* do somethig */ else /* do somethig else */ // oops! Is every set of paretheses matched? if (a // oops! x = f(y); The compiler geerally reports this kid of error late It does t kow you did t mea to close it later 23 First get the program to compile Is every ame declared? Did you iclude eeded headers? (e.g., std_lib_facilities.h) Is every ame declared before it s used? Did you spell all ames correctly? it cout; /* */ ++Cout; // oops! char ch; /* */ Ci>>c; // double oops! Did you termiate each expressio statemet with a semicolo? x = sqrt(y)+2 z = x+3; // oops! 24 6

7 Debuggig Carefully follow the program through the specified sequece of steps Preted you re the computer executig the program Does the output match your expectatios? If there is t eough output to help, add a few debug output statemets cerr << "x == " << x << ", y == " << y << '\'; Be very careful See what the program specifies, ot what you thik it should say That s much harder to do tha it souds for (it i=0; 0<moth.size(); ++i) for( it i = 0; i<=max; ++j) // oops! // oops! (twice) 25 Debuggig Whe you write the program, isert some checks ( saity checks ) that variables have reasoable values Fuctio argumet checks are promiet examples of this if (umber_of_elemets<0) error("impossible: egative umber of elemets"); if (largest_reasoable<umber_of_elemets) error("uexpectedly large umber of elemets"); if (x<y) error("impossible: x<y"); Desig these checks so that some ca be left i the program eve after you believe it to be correct It s almost always better for a program to stop tha to give wrog results 26 Debuggig Pay special attetio to ed cases (begiigs ad eds) Did you iitialize every variable? To a reasoable value Did the fuctio get the right argumets? Did the fuctio retur the right value? Did you hadle the first elemet correctly? The last elemet? Did you hadle the empty case correctly? No elemets No iput Did you ope your files correctly? more o this i chapter 11 Did you actually read that iput? Write that output? Debuggig If you ca t see the bug, you re lookig i the wrog place It s easy to be coviced that you kow what the problem is ad stubborly keep lookig i the wrog place Do t just guess, be guided by output Work forward through the code from a place you kow is right so what happes ext? Why? Work backwards from some bad output how could that possibly happe? Oce you have foud the bug carefully cosider if fixig it solves the whole problem It s commo to itroduce ew bugs with a quick fix I foud the last bug is a programmer s joke

8 Note Error hadlig is fudametally more difficult ad messy tha ordiary code There is basically just oe way thigs ca work right There are may ways that thigs ca go wrog The more people use a program, the better the error hadlig must be If you break your ow code, that s your ow problem Ad you ll lear the hard way If your code is used by your frieds, ucaught errors ca cause you to lose frieds If your code is used by stragers, ucaught errors ca cause serious grief Ad they may ot have a way of recoverig Pre-coditios What does a fuctio require of its argumets? Such a requiremet is called a pre-coditio Sometimes, it s a good idea to check it it area(it legth, it width) // calculate area of a rectagle // legth ad width must be positive if (legth<=0 width <=0) throw Bad_area; retur legth*width; Post-coditios Pre- ad post-coditios What must be true whe a fuctio returs? Such a requiremet is called a post-coditio it area(it legth, it width) // calculate area of a rectagle // legth ad width must be positive if (legth<=0 width <=0) throw Bad_area; // the result must be a positive it that is the area // o variables had their values chaged retur legth*width; Always thik about them If othig else write them as commets Check them where reasoable Check a lot whe you are lookig for a bug This ca be tricky How could the post-coditio for area() fail after the precoditio succeeded (held)?

9 Testig How do we test a program? Be systematic peckig at the keyboard is okay for very small programs ad for very iitial tests, but is isufficiet for real systems Thik of testig ad correctess from the very start Whe possible, test parts of a program i isolatio E.g., whe you write a complicated fuctio write a little program that simply calls it with a lot of argumets to see how it behaves i isolatio before puttig it ito the real program (this is typically called uit testig ) We ll retur to this questio i Chapter 26 The ext lecture I the ext two lectures, we ll discuss the desig ad implemetatio of a complete small program a simple desk calculator