The DvdDatabase Class - SCJD Exam with J2SE 5 - page 130

If you decided that your method will ignore interruptions, then it would be wise to men-
tion this in your Javadoc comments so that users are aware of this—and don't phone you in
the middle of the night asking why they can't interrupt a thread they created.
Wrapping the Exception Within an Allowed Exception
In most cases exceptions cannot be as easily ignored as in the last example. If an IOException
occurs while writing to file, you cannot just ignore it or you will end up with corrupted data.
We created a fictitious business rule that allowed us to ignore the InterruptedException in the
last example, but if that business rule did not exist, then clients may have a right to expect that
they can interrupt their own threads.
One way to handle this is to wrap the caught exception within the exception we are
allowed to throw, as shown in the next bit of code. The output from running this is shown
in Figure 5-4.
38 } catch (InterruptedException ie) {
39a throw new LockAttemptFailedException(
39b "InterruptedException in getLock",
39c ie);
40 }
Figure 5-4. Wrapping the exception within an allowed exception
As can be seen in Figure 5-4, we received a warning message, telling us that we had a
LockAttemptFailedException with the expected stack trace. This log message came from
our LockAttemptFailedException handler at line 26. More importantly, though, the log also
contains lines starting with Caused by: . If you look at these lines, you will see that they are the
same lines that were output in Figure 5-3. By wrapping the InterruptedException inside the
LockAttemptFailedException , we ensured that we still have the complete stack trace from the
InterruptedException .