Exceptions are events that disrupt normal program flow. There are three main types: checked exceptions for anticipated errors, errors for unanticipated external errors, and runtime exceptions for unanticipated internal errors. Exceptions separate error handling code from regular code, allow errors to propagate up the call stack, and group error types into a class hierarchy. Well-designed exceptions indicate broken contracts between code modules. Developers should throw specific exception types to indicate different error conditions rather than generic exceptions.

1. Exceptions
Asif Tasleem
asiftasleem@gmail.com
asiftasleem.blogspot.com
http://sa.linkedin.com/in/asiftasleem

2. What is an Exception?
• An exception is an event, which occurs during the
execution of a program, that disrupts the normal
flow of the program's instructions.

3. Throwable Family

4. Exceptions Types
• Checked Exceptions
– These are exceptional conditions that a well-written application should
anticipate and recover from. Checked exceptions are subject to the
Catch or Specify Requirement.
• Error
– These are exceptional conditions that are external to the application,
and that the application usually cannot anticipate or recover from.
Errors are not subject to the Catch or Specify Requirement.
• Runtime Exceptions
– These are exceptional conditions that are internal to the application, and
that the application usually cannot anticipate or recover from. These
usually indicate programming bugs, such as logic errors or improper use
of an API. Runtime exceptions are not subject to the Catch or Specify
Requirement.

5. Exceptions Types

6. Why Exceptions

7. 1: Separating Error-Handling
Code from "Regular" Code
• Consider the pseudocode method here that reads an entire file
into memory.
readFile {
open the file;
determine its size;
allocate that much memory;
read the file into memory;
close the file;
}

8. 1: Separating Error-Handling Code from
"Regular" Code (Cont.)
At first glance, this function seems simple
enough, but it ignores all the following
potential errors.
– What happens if the file can't be opened?
– What happens if the length of the file can't be
determined?
– What happens if enough memory can't be
allocated?
– What happens if the read fails?
– What happens if the file can't be closed?

9. 1: Separating Error-Handling Code from
"Regular" Code (Cont.)

10. 1: Separating Error-Handling Code from
"Regular" Code (Cont.)

11. 2: Propagating Errors Up the
Call Stack

12. 2: Propagating Errors Up the
Call Stack (Cont.)

13. 2: Propagating Errors Up the
Call Stack (Cont.)

14. 3: Grouping and Differentiating
Error Types
• As all exceptions thrown within a program are objects, the grouping
or categorizing of exceptions is a natural outcome of the class
hierarchy.
– A handler can handle only one type of exception.
– catch (FileNotFoundException e) {
...
– }
– A handler can handle a group of exceptions.
– catch (IOException e) {
...
– }
– We could even set up an exception handler that handles any Exception catch
(Exception e) {
...
– }

15. Designing with Exceptions

16. Exceptions indicate a
broken contract
• Design by Contract
– A software design approach that says that a method represents a contract between the client
(the caller of the method) and the class that declares the method. The contract includes
preconditions that the client must fulfill and post conditions that the method itself must fulfill.
• Precondition
– One example of a method with a precondition is the charAt(int index) method of
class String. This method requires that the index parameter passed by the client be
between 0 and one less than the value returned by invoking length() on the String object.
In other words, if the length of a String is 5, the index parameter must be between 0 and
4, inclusive.
• Postcondition
– The postcondition of String's charAt(int index) method is that its return value will be
the character at position index and the string itself will remain unchanged.

17. Unchecked Exceptions
The Controversy
• Don’t create a subclass
of RuntimeException simply because you don't
want to be bothered with specifying the
exceptions your methods can throw.

18. What to throw?
• Exception vs Error
– Leave the errors to the big guys.
• Checked vs Unchecked exceptions
– If you are throwing an exception for an abnormal condition
that you feel client programmers should consciously decide
how to handle, throw a checked exception.
• Define a specific exception class
– Don't just throw Exception, for example, with a string
message indicating the kind of abnormal condition that
caused the exception.

19. What to throw? (Cont.)
• If your method encounters an abnormal condition that it can't handle, it
should throw an exception.
• Avoid using exceptions to indicate conditions that can reasonably be
expected as part of the normal functioning of the method.
• If your method discovers that the client has breached its contractual
obligations (for example, by passing in bad input data), throw an
unchecked exception.
• If your method is unable to fulfill its contract, throw either a checked or
unchecked exception.
• If you are throwing an exception for an abnormal condition that you feel
client programmers should consciously decide how to handle, throw a
checked exception.
• Define or choose an already existing exception class for each kind of
abnormal condition that may cause your method to throw an exception.

20. Thank You