#1ExceptionsExceptions#2 “Wizard is about to die.”•PA5 checkpoint is due Thu Nov 19th – just over a week from now.• I have zero auto-tester submissions so far.– I am predicting that you haven't started PA5 yet.• You will have second midterms in this class (and others!) soon. •If you can't compile hello-world.cl by the end of this weekend, I forsee regret, remorse and lack of sleep in your future.#3One-Slide Summary• Real-world programs must have error-handling code. Errors can be handled where they are detected or the error can be propagated to a caller. • Passing special error return codes is itself error-prone. •Exceptions are a formal and automated way of reporting and handling errors. Exceptions can be implemented efficiently and described formally.#4Language System Structure• We looked at each stage in turn•A new language feature affects many stages• We will add exceptionsSourceLexerParserCode GeneratorRuntime SystemRun it!Type checker#5Lecture Summary• Why exceptions ?•Syntax and informal semantics•Semantic analysis (i.e., type checking rules)• Operational semantics•Code generation•Runtime system support#6Exceptional Motivation• “Classroom” programs are written with optimistic assumptions• Real-world programs must consider “exceptional” situations:–Resource exhaustion (disk full, out of memory, network packet collision, …)– Invalid input–Errors in the program (null pointer dereference)• It is usual for code to contain 1-5% error handling code (figures for modern Java open source code)–With 3-46% of the program text transitively reachable#7Why do we care?• Are there any implications if software makes mistakes?#8Approaches To Error HandlingTwo ways of dealing with errors:•Handle them where you detect them•e.g., null pointer dereference ! stop execution• Let the caller handle the errors:• The caller has more contextual informatione.g. an error when opening a file:b) In the context of opening /etc/passwdc) In the context of opening a log file • But we must tell the caller about the error!#9Error Return Codes• The callee can signal the error by returning a special return value or error code:– Must not be one of the valid inputs– Must be agreed upon beforehand (i.e., in API)•What's an example?•The caller promises to check the error return and either:– Correct the error, or– Pass it on to its own caller#10Error Return Codes• It is sometimes hard to select return codes– What is a good error code for:•divide(num: Double, denom: Double) : Double { … } •How many of you always check errors for:– malloc(int) ?– open(char *) ?– close(int) ?– time(struct time_t *) ?•Easy to forget to check error return codes#11Example: Automated Grade Assignment float getGrade(int sid) { return dbget(gradesdb, sid); }void setGrade(int sid, float grade) { dbset(gradesdb, sid, grade); }void extraCredit(int sid) {setGrade(sid, 0.33 + getGrade(sid));}void grade_inflator() {while(gpa() < 3.0) { extraCredit(random()); } }• What errors are we ignoring here?#12Example: Automated Grade Assignment float getGrade(int sid) { float res; int err = dbget(gradesdb, sid, &res); if(err < 0) { return -1.0;} return res;}int extraCredit(int sid) { int err; float g = getGrade(sid); if(g < 0.0) { return 1; } err = setGrade(sid, 0.33 + g)); return (err < 0); }#13Example: Automated Grade Assignment float getGrade(int sid) { float res; int err = dbget(gradesdb, sid, &res); if(err < 0) { return -1.0;} return res;}int extraCredit(int sid) { int err; float g = getGrade(sid); if(g < 0.0) { return 1; } err = setGrade(sid, 0.33 + g)); return (err < 0); }A lot of extracode#14Example: Automated Grade Assignment float getGrade(int sid) { float res; int err = dbget(gradesdb, sid, &res); if(err < 0) { return -1.0;} return res;}int extraCredit(int sid) { int err; float g = getGrade(sid); if(g < 0.0) { return 1; } err = setGrade(sid, 0.33 + g)); return (err < 0); }Some functions change their typeA lot of extracode#15Example: Automated Grade Assignment float getGrade(int sid) { float res; int err = dbget(gradesdb, sid, &res); if(err < 0) { return -1.0;} return res;}int extraCredit(int sid) { int err; float g = getGrade(sid); if(g < 0.0) { return 1; } err = setGrade(sid, 0.33 + g)); return (err < 0); }Some functions change their typeError codes are sometimes arbitraryA lot of extracode#16Exceptions•Exceptions are a language mechanism designed to allow: – Deferral of error handling to a caller– Without (explicit) error codes– And without (explicit) error return code checking#17Adding Exceptions to Cool• We extend the language of expressions:e ::= throw e | try e catch x : T ) e2•(Informal) semantics of throw e– Signals an exception– Interrupts the current evaluation and searches for an exception handler up the activation tree– The value of e is an exception parameter and can be used to communicate details about the exception#18Adding Exceptions to Cool(Informal) semantics of try e catch x : T ) e2– e is evaluated first– If e’s evaluation terminates normally with v then v is the result of the entire expression Else (e’s evaluation terminates exceptionally) If the exception parameter is of type · T then–Evaluate e2 with x bound to the exception parameter– The (normal or exceptional) result of ev–aluating e2 becomes the result of the entire expression Else– The entire expression terminates exceptionally#19Example: Automated Grade Assignmentfloat getGrade(int sid) { return dbget(gradesdb, sid); }void setGrade(int sid, float grade) { if(grade < 0.0 || grade > 4.0) { throw (new NaG); }dbset(gradesdb, sid, grade); }void extraCredit(int sid) {setGrade(sid, 0.33 + getGrade(sid)) }void grade_inflator() {while(gpa < 3.0) { try extraCredit(random()) catch x : Object ) print “Aie!?\n”; } }#20Example Notes• Only error handling code remains•But no error propagation code– The compiler handles the error propagation– No way to forget about it–And also much more efficient (we’ll see)•Two kinds of evaluation outcomes:–Normal return (with a return value)– Exceptional “return” (with an exception parameter)– No way to get confused which is which#21Where do exceptions come from?#22OverviewWhy exceptions ?Syntax and informal semantics•Semantic analysis (i.e. type checking rules)• Operational semantics•Code generation•Runtime