Exceptions and Exception Handling
CSSE 221: Fundamentals of Software Development Honors
Fall 2008–2009
Work on this exercise by yourself,
but
be quick to ask questions of your instructor, student assistants and classmates as desired.
Consider:
When you see “Consider” in red,
where do you go to report your answer to that question?
- Hint: You go to the report
for the exercise,
located in Angel ~ Lessons ~ Assessment ~ Project Reports.
Go to Angel now and report your answer to this question.
Consider:
When you see “Consider” in red,
do you go to the Angel report to answer that question right at that time
or do you wait until you have done the rest of the exercise?
Consider:
When you see “Consider” in red,
at that point
do you answer only the single question in that “Consider”
or all the questions in the Angel report?
Goals
The goals of this exercise are to apply and hence reinforce your understanding of:
- What exceptions are
- When exceptions should (and should not) be used
- What is means to "throw" and "catch" an exception
- How to throw an exception
- How to declare that a method throws an exception
- How to write try-catch blocks
The Exercise - Overview
Exceptions are a formal method used to respond to situations in Java
where something unexpected happens (usually, but not always an error).
The basic vocabulary reflects the unusual situation: when an unusual situation occurs,
an object called an exception is thrown by one segment of code,
and another segment of code catches the exception and handles it.
This entire block of code is called a try-catch block.
In this exercise you will:
- Examine existing exception handling code
in a program that dispenses rudimentary nutritional advice.
- Modify that code to understand the Exception subclasses and how throws works.
Instructions, Part 1 - Checkout the Project
- Open Eclipse.
- Checkout your Exceptions project.
- You can look at the JavaEyes instructions
to remind yourself how to checkout a project
from your individual repository for this course.
Instructions, Part 2 - Reading try/catch/finally
- Run the project a few times, doing the following things:
- Follow the instructions - give it each asked-for numeric answer
(1, then 2, then 3, then 4, then 5).
- Mis-read the instructions, as follows:
- Give it a weekend day.
- Give it a larger-than-7 number.
- Give it a negative number.
- Really mis-read the instructions, as follows:
- Give it a non-numeric answer.
- Give it a very large integer like 888888888888888888888888888
- Give it no input, by typing control-z
- Examine the code that produced each of the above responses.
- Maybe not the structures you would have used to write it?
Consider:
In general, what is the purpose of a catch block?
Consider:
In general, what is the purpose of a throw statement?
Consider:
In general, what is the purpose of a finally block?
Consider:
When an exception is thrown in the try block
and caught in the catch block,
does the code in the finally block run before or after the code
in the catch block?
Instructions, Part 3 - Choosing the right Exceptions to throw/catch
-
Consider:
What Exception is thrown when the user gives non-numeric input?
Consider:
As it stands, does the code catch the Exception that is thrown when the user gives non-numeric input?
Consider:
What Exception is thrown when the user gives no input (by typing control-z)?
Consider:
As it stands, does the code catch the Exception that is thrown
when the user gives no input (by typing control-z)?
Consider:
What Exception is thrown when the user gives 3 as the input?
Consider:
As it stands, does the code catch the Exception that is thrown
when the user gives 3 as the input?
Consider:
When the user gives 5 as the input,
instead of printing 2.5 billion, the program prints -1794967296.
Why?
Consider:
When overflow occurs, does the Java Virtual Machine throw an Exception?
Consider:
When overflow occurs, does the Java Virtual Machine throw an Error?
- As it stands, the code catches the divide-by-zero bug and prints a confusing error message to the user.
This occurs because the code, as written,
violates the Quality Tip to Throw and Catch Specific Exceptions.
- If you don't see that this tip is violated, and why that causes confusion when
the divide-by-zero bug occurs, ask your instructor or an assistant for an explanation now.
Modify the code so that it obeys the Quality Tip, and hence does not catch the divide-by-zero bug.
- As it stands, the code does not catch non-numeric and null inputs.
Modify the code so that it does catches these and prints meaningful messages to the user in each case.
- As it stands, the code does not close the Scanner object when it is finished doing input.
Modify the code so that it closes the Scanner object.
Instructions, Part 4 - throws
- As it stands, the code violates the Quality Tip to Throw Early, Catch Late.
Experiment, and eventually fix this, by following these steps:
- Write a new static void method called processIt,
that takes the day as a parameter,
and move the entire try-catch-finally block inside it.
Don't move anything else into processIt.
- Execute the project and make any modifications
to make sure it still appears to the user to work exactly as it did before.
- Now, change your program so that processIt throws the exceptions
and getWeekday catches the exceptions.
Consider:
Does it handle all the input cases the same as before?
Now, change it so that main catches the exceptions.
Consider:
Does it handle all the input cases the same as before?
Now, change it so that the exceptions are never caught,
i.e., even main fails to catch them.
Note that this is bad programming practice.
Consider:
Does it handle all the input cases the same as before?
- Finally, return your code to the way it was when getWeekday catches the exceptions.
Instructions, Part 5 - Turn in your work (i.e., commit your project)
- Make sure that your project has correct style.
Make sure that there is appropriate HTML documentation
for all your public methods.
- Commit your Exceptions project to the repository from which you checked it out.
- You can look at the JavaEyes instructions
to remind yourself how to commit a project
to the repository from which it was checked out.