Inheritance - Data Structures and Problem Solving Using Java - page 138

figure 4.19
NoSuchElementException ,
implemented in
weiss.util

1 package weiss.util;
2
3 public class NoSuchElementException extends RuntimeException
4 {
5 /**
6 * Constructs a NoSuchElementException with
7 * no detail message.
8 */
9 public NoSuchElementException( )
10 {
11 }
12
13 /*
14 * Constructs a NoSuchElementException with
15 * a detail message.
16 * @param msg the detail message.
17 */
18 public NoSuchElementException( String msg )
19 {
20 super( msg );
21 }
22 }

defines a set of printStackTrace methods, provides a toString implementation,
a pair of constructors, and little else. The hierarchy is split off into Error ,
RuntimeException , and checked exceptions. A checked exception is any
Exception that is not a RuntimeException . For the most part, each new class
extends another exception class, providing only a pair of constructors. It is
possible to provide more, but none of the standard exceptions bother to do so.
In weiss.util , we implement three of the standard java.util exceptions. One
such implementation, which shows that new exception classes typically
provide little more than constructors, is shown in Figure 4.19.

4.5.3 i/o: the decorator pattern

I/O in Java looks fairly complex to use but works nicely for doing I/O with
different sources, such as the terminal, files, and Internet sockets. Because it is
designed to be extensible, there are lots of classes—over 50 in all. It is cumber-
some to use for trivial tasks; for instance, reading a number from the terminal
requires substantial work.
Input is done through the use of stream classes. Because Java was
designed for Internet programming, most of the I/O centers around byte-
oriented reading and writing.