DOC PREVIEW
UMD CMSC 330 - Exceptions

This preview shows page 1-2 out of 7 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CMSC 330: Organization of Programming Languages Exceptions CMSC 330 2 Preconditions • Functions often have requirements on their inputs // Return maximum element in A[i..j] int findMax(int[] A, int i, int j) { ... } – A is nonempty – A isn't null – i and j must be nonnegative – i and j must be less than A.length – i < j (maybe) • These are called preconditions CMSC 330 3 Dealing with Errors • What do you do if a precondition isn’t met? • What do you do if something unexpected happens? – Try to open a file that doesn’t exist – Try to write to a full disk CMSC 330 4 Signaling Errors • Style 1: Return invalid value // Returns value key maps to, or null if no // such key in map Object get(Object key); – Disadvantages?CMSC 330 5 Signaling Errors (cont’d) • Style 2: Return an invalid value and status static int lock_rdev(mdk_rdev_t *rdev) { ... if (bdev == NULL) return -ENOMEM; ... } // Returns NULL if error and sets global // variable errno FILE *fopen(const char *path, const char *mode); CMSC 330 6 Problems with These Approaches • What if all possible return values are valid? – E.g., findMax from earlier slide – What about errors in a constructor? • What if client forgets to check for error? – No compiler support • What if client can’t handle error? – Needs to be dealt with at a higher level • Poor modularity- exception handling code becomes scattered throughout program • 1996 Ariane 5 failure classic example of this … CMSC 330 7 Ariane 5 failure Design issues: In order to save funds and ensure reliability, and since the French Ariane 4 was a successful rocket, the Inertial Reference System (SRI) from Ariane 4 was reused for the Ariane 5. What happened?: On June 4, 1996 the Ariane 5 launch vehicle failed 39 seconds after liftoff causing the destruction of over $100 million in satellites. Cause of failure: The SRI, which controls the attitude (direction) of the vehicle by sending aiming commands to the rocket nozzle, sent a bad command to the rocket causing the nozzle to move the rocket toward the horizontal. The vehicle tried to switch to the backup SRI, but that failed for the same reason 72 millisec earlier. The vehicle had to then be destroyed. CMSC 330 8 Why Ariane 5 failed • SRI tried to convert a floating point number out of range to integer. Therefore it issued an error message (as a 16 bit number). This 16 bit number was interpreted as an integer by the guidance system and caused the nozzle to move accordingly. – The backup SRI performed according to specifications and failed for the same reason. • Ada range checking was disabled since the SRI was supposedly processing at 80% load and the extra time needed for range checking was deemed unnecessary since the Ariane 4 software worked well. • The ultimate cause of the problem was that the Ariane 5 has a more pronounced angle of attack and can move horizontally sooner after launch. The “bad value” was actually the appropriate horizontal speed of the vehicle.CMSC 330 9 Better approaches: Exceptions in Java • On an error condition, we throw an exception • At some point up the call chain, the exception is caught and the error is handled • Separates normal from error-handling code • A form of non-local control-flow – Like goto, but structured CMSC 330 10 Throwing an Exception • Create a new object of the class Exception, and throw it if (i >= 0 && i < a.length ) return a[i]; throw new ArrayIndexOutOfBounds(); • Exceptions thrown are part of the return type in Java – When overriding method in superclass, cannot throw any more exceptions than parent’s version CMSC 330 11 Method throws declarations • A method declares the exceptions it might throw – public void openNext() throws UnknownHostException, EmptyStackException { … } • Must declare any exception the method might throw – Unless it is caught in (masked by) the method – Includes exceptions thrown by called methods – Certain kinds of exceptions excluded CMSC 330 12 Exception Hierarchy Throwable Error Exception RuntimeException Checked UncheckedCMSC 330 13 • Subclasses of RuntimeException and Error are unchecked – Need not be listed in method specifications • Currently used for things like – NullPointerException – IndexOutOfBoundsException – VirtualMachineError • Is this a good design? Unchecked Exceptions CMSC 330 14 • All exceptions eventually get caught • First catch with supertype of the exception catches it • finally is always executed try { if (i == 0) return; myMethod(a[i]); } catch (ArrayIndexOutOfBounds e) { System.out.println(“a[] out of bounds”); } catch (MyOwnException e) { System.out.println(“Caught my error”); } catch (Exception e) { System.out.println(“Caught” + e.toString()); throw e; } finally { /* stuff to do regardless of whether an exn*/ /* was thrown or a return taken */ } Exception Handling CMSC 330 15 The Development of Exceptions • Lisp 1.5 (mid-1950s) – Certain built-in functions could trigger errors • Would result in program termination or debugger entry – errset e • Evaluate e, and ignore any errors that occurred – Key: wanted to be able to continue execution after an error CMSC 330 16 Development of Exns (cont’d) • PL/I (mid-1960s) – “ON-units” can be established for a block to handle one of 23 predefined errors – Most recently established ON-unit used for condition • And exit from a block cancels ON-units for it • Like nested try/catch blocks • Turned out to be difficult to use – Needed to use global variables to communicate with exception handling code – Fixup actions occurred where ON statement executed • Led to some strange behaviorCMSC 330 17 Development of Exns (cont’d) • Throw within ON-unit resulted in recursion FACTORIAL: PROC; DCL (N INIT(1) ,F INIT(1)) FIXED BIN (31); ON FINISH BEGIN; PUT LIST (N, "FACTORIAL =", F) ; PUT SKIP; N = N + 1; F = N * F STOP; END; STOP; END FACTORIAL; Raise FINISH condition (jump to top of loop, indefinitely until overflow) Source: MacLaren, Exception Handling in PL/I CMSC 330 18 Development of Exns (cont’d) • CLU (mid-1970s) – A language designed


View Full Document

UMD CMSC 330 - Exceptions

Documents in this Course
Exam #1

Exam #1

6 pages

Quiz #1

Quiz #1

2 pages

Midterm 2

Midterm 2

12 pages

Exam #2

Exam #2

7 pages

Ocaml

Ocaml

7 pages

Parsing

Parsing

38 pages

Threads

Threads

12 pages

Ruby

Ruby

7 pages

Quiz #3

Quiz #3

2 pages

Threads

Threads

7 pages

Quiz #4

Quiz #4

2 pages

Exam #2

Exam #2

6 pages

Exam #1

Exam #1

6 pages

Threads

Threads

34 pages

Quiz #4

Quiz #4

2 pages

Threads

Threads

26 pages

Exam #2

Exam #2

9 pages

Exam #2

Exam #2

6 pages

Load more
Download Exceptions
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Exceptions and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Exceptions 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?