Exceptions - Exceptions Page 1 of 9 EXCEPTIONS Contents...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
E XCEPTIONS Contents z Error Handling z Exceptions { How to Catch Exceptions { Checked and Unchecked Exceptions { Exception Hierarchy { Choices when calling a method that may throw an exception { Test Yourself #1 { How to Define and Throw Exceptions { Test Yourself #2 z Summary Error Handling Runtime errors can be divided into low-level errors that involve violating constraints, such as: z dereference of a null pointer z out-of-bounds array access z divide by zero z attempt to open a non-existent file for reading z bad cast (e.g., casting an Object that is actually a Boolean to Integer) and higher-level, logical errors, such as violations of a method's precondition: z a call to an Iterator's "next" method when there are no more items z a call to a List's "get" method when the list is empty z a call to "factorial" with a negative number Logical errors can lead to low-level errors if they are not detected. Often, it is better to detect them (to provide better feedback). Errors can arise due to: z User error (for example, providing a bad file name or a poorly formatted input file). A good program should be written to anticipate these situations, and should deal with them. For example, given a bad file name, an interactive program could print an error message and prompt for a new name. z Programmer error (i.e., a buggy program). These errors should be detected as early as possible to provide good feedback. For some programs it may be desirable to do some recovery after detecting this kind of error; for example, writing out current data. Page 1 of 9 Exceptions 2008/3/27 http://pages.cs.wisc.edu/~cs367-1/topics/Exceptions/
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Note that recovery is often not possible at the point of the error (because the error may occur inside some utility method that doesn't know anything about the overall program or what error recovery should involve). Therefore, it is desirable to "pass the error up" to a level that can deal with it. There are several possible ways to handle errors: z Write an error message and quit. This doesn't provide any recovery. z Return a special value to indicate that an error occurred. This is the usual approach for C functions (which often return 0 or -1 to signal an error). However: { It doesn't work if the method also returns a value on normal completion and all values are possible (i.e., there is no special value that can be used to signal an error). { It requires that calling code check for an error. This can reduce the efficiency of the code, and is often omitted by programmers out of laziness or carelessness. { It can sometimes make the code more clumsy. For example, if method g might return an error code, one would have to write something like: instead of just: z Use a reference parameter or a global variable to hold an error code . This solves the first problem of the previous approach, but not the second or third ones. z
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}

Page1 / 9

Exceptions - Exceptions Page 1 of 9 EXCEPTIONS Contents...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online