TIJ——Chapter Twelve:Error Handling with Exception

Exception guidelines

Use exceptions to:

• Handle problems at the appropriate level.(Avoid catching exceptions unless you know what to do with them.)
• Fix the problem and call the method that caused the exception again.
• Patch things up and continue without retrying the method.
• Calculate some alternative result instead of what the method was supposed to produce.
• Do whatever you can in the current context and rethrow the same exception to a higher context.
• Do whatever you can in the current context and throw a different exception to a higher context.
• Terminate the program.
• Simplify.(If your exception scheme make things more complicated, then it is painful and annoying to use.)
• Make your library and program safer.(This is a short-term investment of debugging, and a long-term investment for application robustness.)

---

• If you're inside a method and you throw an exception(or another method that you call within this method throws an exception), that method will exit in the process of throwing. If you don't  want a throws to exit the method, you can set up a special block within that method to capture the exception. This is called the try block because you "try" your various method calls there.
• Exercise: Create your own resumption-like behavior using a while loop that repeats until an exception is no longer thrown.

class ResumerException extends Exception {}

class Resumer
{
	static int count = 3;
	static void f() throws ResumerException
	{
		if(--count > 0)
			throw new ResumerException();
	}
}

public class Test
{
	public static void main(String[] args)
	{
		while(true)
		{
			try
			{
				Resumer.f();
			}
			catch(ResumerException e)
			{
				System.out.println("Caught " + e);
				continue;
			}
			System.out.println("Got through...");
			break;
		}
		System.out.println("Successful execution");
	}
}
/* Output:
Caught com.tij.ibook.ResumerException
Caught com.tij.ibook.ResumerException
Got through...
Successful execution
*/

　　由上面的代码，可以给我们启示：我们甚至可以指定出现异常的代码最多执行的次数。比如，有一个可能会由于我们的网络不稳定等原因导致的网络连接超时异常，这时我们可以尝试再次连接。通过这种方式，我们可以构建更加健壮的程序。

• The Java class Throwable describes anything that can be thrown as an exception. There are two general type of Throwable objects("types of"="inherited from"). 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.
• There's whole group of exception types that are in this category. They're always thrown automatically by Java and you don't need to include them in your exception specifications, Conveniently enough, they're all grouped together by putting them under a single base class called RuntimeException, which is a perfect example of inheritance: It establishes a family of types that have some characteristics and behaviors in common. Also, you never need to write an exception specification saying that a method might throw a RuntimeException(or any type inherited from RuntimeException), because they are unchecked exceptions.
• If a RuntimeException gets all the way out to main() without being caught, printStackTrace() is called for that exception as the program exits.
• Keep in mind that only exceptions of type RuntimeException(and subclass) can be ignored in your coding, since the compiler carefully enforces the handling of all checked exceptions. The reasoning is that a RuntimeException represents a programming error, which is:
  1. (#1)  An error you cannot anticipate. For example, a null reference that is outside of your control.
  2. (#2)  An error that tyou, as a programmer, should have checked for in your code(such as ArrayIndexOutOfBoundsException where you should have paid attention to the size of array). An exception that happens from point #1 often becomes an issue for point #2.
• You can see what a tremendous benifit it is to have exception in Java, since they help in the debugging process.
• In a language without garbage collection and without automatic destructor calls, finally is important because it allows the programmer to guarantee the release of memory regardless of what happens in the try block. But Java has garbage collection, so releasing memory is virtually never a problem. Also, it has no destructors to call. So when do you need to use finally in Java? The finally clause is necessary when you need to set something other than memory back to its original state. Such as some kind of cleanup like an open file or network connection, something you've drawn on the screen, or even a swith in the outside world.
• The finally statement will also be executed in situations in which break, continue and return statements are involved.
• When you override a method, you can throw only the exceptions that hava been specified in the base-class will automatically work with any object derived from the base class(a fundamental OOP concept, of course), including exceptions. By forcing the derived-class methods to conform to the exception specifications of the base-class methods, substitutability of objects is maintained. The restiction on exception does not apply to constructors. 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, the derived-class constructor must declare any base-class constructor exceptions in its exception specification. All these constraints produce much more robust exceptionhandling code.
• 通过多个catch 块来捕获异常时，需要把父类型的catch 块放到子类型的catch 块之后，否则编译器会因子类型的catch 无法到达而报错。
• The exception specification, to programmatically state in the method signature the exceptions that could result from calling that method. The exception specification really has two purposes. It can say, "I'm originating this exception in my code; you handle it." But it can also mean, "I'm ignoring this exception that can occur as a result of my code; you handle it." We've been focusing on the "you handle it" part when looking at the machanics and syntax of exceptions, but here I'm particularly interested in the fact that we often ignore exception and that's what the exception specification can state.

A good programming language is one that helps programmers write good programs. No programming language will prevent its users from writing bad programs.