Thinking in Java (Chapter 12)
===
###### tags: `Java` `OOP`
1. implementations of exception handling go back to operating systems in the 1960s, and even to BASIC’S "on error goto." But C++ exception handling was based on Ada, and Java’s is based primarily on C++ (although it looks more like Object Pascal).
1. the exception object is created on the heap, with new
1. You can also exit from ordinary scopes by throwing an exception. In either case, an exception object is returned, and the method or scope exits.
1. within the try block, a number of different method calls might generate the same exception, but you need only one handler
1. Java supports termination, 3 in which you assume that the error is so critical that there’s no way to get back to where the exception occurred.
1. A resumptive handler would need to be aware of where the exception is thrown, and contain non-generic code specific to the throwing location
1. send error output to the standard error stream by writing to System.err. This is usually a better place to send error information than System.out
1. The static Logger.getLogger( ) method creates a Logger object associated with the String argument (usually the name of the package and class that the errors are about) which sends its output to System.err.
1. The easiest way to write to a Logger is just to call the method associated with the level of logging message like severe( )
1. To produce the String for the logging message, we’d like to have the stack trace where the exception is thrown, but printStackTrace( ) doesn’t produce a String by default. To get a String, we need to use the overloaded printStackTrace( ) that takes a java.io.PrintWriter object as an argument (all of this will be fully explained in the I/O chapter). If we hand the Print Writer constructor a java.io.StringWriter object, the output can be extracted as a String by calling toString( ).
1. getMessage( ) is something like toString( ) for exception classes.
1. exception specification is part of the method declaration, appearing after the argument list.
1. You can claim to throw an exception that you really don’t. The compiler takes your word for it, and forces the users of your method to treat it as if it really does throw that exception.
1. String getMessage( ) String getLocalizedMessage( ) Gets the detail message, or a message adjusted for this particular locale. String toString( ) Returns a short description of the Throwable, including the detail message if there is one. void printStackTrace( ) voidprintStackTrace(PrintStream) voidprintStackTrace(java.io.PrintWriter) Prints the Throwable and the Throwable’s call stack trace. The call stack shows the sequence of method calls that brought you to the point at which the exception was thrown. The first version prints to standard error, the second and third print to a stream of your choice (in the I/O chapter, you’ll understand why there are two types of streams). Throwable fillInStackTrace( ) Records information within this Throwable object about the current state of the stack frames. Useful when an application is rethrowing an error or exception (more about this shortly). In addition, you get some other methods from Throwable’s base type Object (everybody’s base type). The one that might come in handy for exceptions is getClass( ), which returns an object representing the class of this object. You can in turn query this Class object for its name with getName( ), which includes package information, or getSimpleName( ), which produces the class name alone.
1. The information provided by printStackTrace( ) can also be accessed directly using getStackTrace( ).
1. printStackTrace( ) will pertain to the exception’s origin, not the place where you rethrow it. If you want to install new stack trace information, you can do so by calling fillInStackTrace( )
1. Often you want to catch one exception and throw another, but still keep the information about the originating exception—this is called exception chaining
1. the only Throwable subclasses that provide the cause argument in the constructor are the three fundamental exception classes Error (used by the JVM to report system errors), Exception, and RuntimeException. If you want to chain any other exception types, you do it through the initCause( ) method rather than the constructor
1. Error represents compile-time and system errors that you don’t worry about catching (except in very special cases). Exception is the basic type that can be thrown from any of the standard Java library class methods and from your methods and runtime accidents. So the Java programmer’s base type of interest is usually Exception.
1. The finally clause is necessary when you need to set something other than memory back to its original state
1. C++ treats the situation in which a second exception is thrown before the first one is handled as a dire programming error.
1. simpler way to lose an exception is just to return from inside a finally clause:
1. When you override a method, you can throw only the exceptions that have been specified in the base-class version of the method
1. Error throws in interface can’t change the error that’s been thrown in the base class
1. You don’t need to throw no exception even it’s in exception specification
1. A constructor can throw anything it wants, regardless of what the base-class constructor throws. However, since a base-class constructor must always be called one way or another (here, the default constructor is called automatically), the derived-class constructor must declare any base-class constructor exceptions in its exception specification.
1. A derived-class constructor cannot catch exceptions thrown by its base-class constructor.
1. a derived-class version of a method may choose not to throw any exceptions, even if the base-class version does
1. if you upcast to the base type, then the compiler (correctly) forces you to catch the exceptions for the base type
1. you cannot overload methods based on exception specifications. In addition, just because an exception specification exists in a baseclass version of a method doesn’t mean that it must exist in the derived-class version of the method.
1. InputFile is created that opens a file and allows you to read it one line at a time. It uses the classes FileReader and BufferedReader from the Java standard I/O library
1. the exception-handling system looks through the "nearest" handlers in the order they are written. When it finds a match, the exception is considered handled, and no further searching occurs.
1. One of the important guidelines in exception handling is "Don’t catch an exception unless you know what to do with it
1. e they force you to add catch clauses in places where you may not be ready to handle an error. This results in the "harmful if swallowed" problem
1. A unified error-reporting model via exceptions, regardless of whether the programmer is forced by the compiler to handle them.
1. Type checking, regardless of when it takes place. That is, as long as proper use of a type is enforced, it often doesn’t matter if it happens at compile time or run time.
1.
1. the easiest way to preserve the exceptions without writing a lot of code is to pass them out of main( ) to the console
1. With chained exceptions, a new and simple solution prevents itself. You simply "wrap" a checked exception inside a RuntimeException by passing it to the RuntimeException constructor
1. "Reporting" function is where the essential value of exceptions lie