Java™ How to Program, Sixth Edition - Part13

Few weeks back i started reading Java™ How to Program, Sixth Edition By H. M. Deitel - Deitel & Associates, Inc., P. J. Deitel - Deitel & Associates, Inc.

Nice book written By H. M. Deitel - Deitel & Associates, Inc., P. J. Deitel - Deitel & Associates, Inc.

I wanted to share few quotations found the book from the 13th chapter.

1) An exception is an indication of a problem that occurs during a program's execution.

2) Exception handling enables programmers to create applications that can resolve exceptions.

3) Exception handling enables programmers to remove error-handling code from the "main line" of the program's execution, improving program clarity and enhancing modifiability.

4) Exceptions are thrown when a method detects a problem and is unable to handle it.

5) An exception's stack trace includes the name of the exception in a descriptive message that indicates the problem that occurred and the complete method-call stack (i.e., the call chain) at the time the exception occurred.

6) The point in the program at which an exception occurs is called the throw point.

7) A TRy block encloses the code that might throw an exception and the code that should not execute if that exception occurs.

8) Exceptions may surface through explicitly mentioned code in a TRy block, through calls to other methods or even through deeply nested method calls initiated by code in the try block.

9) A catch block begins with the keyword catch and an exception parameter followed by a block of code that catches (i.e., receives) and handles the exception. This code executes when the try block detects the exception.

10) An uncaught exception is an exception that occurs for which there are no matching catch blocks.

11) An uncaught exception will cause a program to terminate early if that program contains only one thread. If the program contains more than one thread, only the thread where the exception occurred will terminate. The rest of the program will run, but may yield adverse effects.

12) At least one catch block or a finally block must immediately follow the try block.

13) Each catch block specifies in parentheses an exception parameter that identifies the exception type the handler can process. The exception parameter's name enables the catch block to interact with a caught exception object.

14) If an exception occurs in a TRy block, the try block terminates immediately and program control transfers to the first of the following catch blocks whose exception parameter type matches the type of the thrown exception.

15) After an exception is handled, program control does not return to the throw point because the try block has expired. This is known as the termination model of exception handling.

16) If there are multiple matching catch blocks when an exception occurs, only the first is executed.

17) After executing a catch block, this program's flow of control proceeds to the first statement after the last catch block.

18) A throws clause specifies the exceptions the method throws, and appears after the method's parameter list and before the method body.

19) The throws clause contains a comma-separated list of exceptions that the method will throw if a problem occurs when the method executes.

20) Exception handling is designed to process synchronous errors, which occur when a statement executes.

21) Exception handling is not designed to process problems associated with asynchronous events, which occur in parallel with, and independent of, the program's flow of control.

22) All Java exception classes inherit, either directly or indirectly, from class Exception. Because of this fact, Java's exception classes form a hierarchy. Programmers can extend this hierarchy to create their own exception classes.

23) Class Throwable is the superclass of class Exception, and is therefore also the superclass of all exceptions. Only Throwable objects can be used with the exception-handling mechanism.

24) Class Throwable has two subclasses: Exception and Error.

25) Class Exception and its subclasses represent exceptional situations that could occur in a Java program and be caught by the application.

26) Class Error and its subclasses represent exceptional situations that could happen in the Java runtime system. Errors happen infrequently, and typically should not be caught by an application.

27) Java distinguishes between two categories of exceptions: checked and unchecked.

28) Unlike checked exceptions, the Java compiler does not check the code to determine whether an unchecked exception is caught or declared. Unchecked exceptions typically can be prevented by proper coding.

29) An exception's type determines whether the exception is checked or unchecked. All exception types that are direct or indirect subclasses of class RuntimeException are unchecked exceptions. All exception types that inherit from class Exception but not from RuntimeException are checked.

30) Various exception classes can be derived from a common superclass. If a catch block is written to catch exception objects of a superclass type, it can also catch all objects of that class's subclasses. This allows for polymorphic processing of related exceptions.

31) Programs that obtain certain types of resources must return them to the system explicitly to avoid so-called resource leaks. Resource-release code typically is placed in a finally block.

32) The finally block is optional. If it is present, it is placed after the last catch block.

33) Java guarantees that a provided finally block will execute whether or not an exception is thrown in the corresponding try block or any of its corresponding catch blocks. Java also guarantees that a finally block executes if a TRy block exits by using a return, break or continue statement.

34) If an exception that occurs in the TRy block cannot be caught by one of that TRy block's associated catch handlers, the program skips the rest of the TRy block and control proceeds to the finally block, which releases the resource. Then the program passes to the next outer try blocknormally in the calling method.

35) If a catch block throws an exception, the finally block still executes. Then the exception is passed to the next outer try blocknormally in the calling method.

36) Programmers can throw exceptions by using the throw statement.

37) A throw statement specifies an object to be thrown. The operand of a tHRow can be of any class derived from class Throwable.

38) Exceptions are rethrown when a catch block, upon receiving an exception, decides either that it cannot process that exception or that it can only partially process it. Rethrowing an exception defers the exception handling (or perhaps a portion of it) to another catch block.

39) When a rethrow occurs, the next enclosing TRy block detects the rethrown exception, and that TRy block's catch blocks attempt to handle the exception.

40) When an exception is thrown but not caught in a particular scope, the method-call stack is unwound, and an attempt is made to catch the exception in the next outer try statement. This process is called stack unwinding.

41) Class THRowable offers a printStackTrace method that prints the method-call stack. Often, this is helpful in testing and debugging.

42) Class THRowable also provides a getStackTrace method that obtains stack-trace information printed by printStackTrace.

43) Class Throwable's getMessage method returns the descriptive string stored in an exception.

44) Method getStackTrace obtains the stack-trace information as an array of StackTraceElement objects. Each StackTraceElement represents one method call on the method-call stack.

45) StackTraceElement methods getClassName, getFileName, getLineNumber and getMethodName get the class name, file name, line number and method name, respectively.

46) Chained exceptions enable an exception object to maintain the complete stack-trace information, including information about previous exceptions that caused the current exception.

47) A new exception class must extend an existing exception class to ensure that the class can be used with the exception-handling mechanism.

48) A method's precondition is a condition that must be true when the method is invoked.

49) A method's postcondition is a condition that is true after the method successfully returns.

50) When designing your own methods, you should state the preconditions and postconditions in a comment before the method declaration.

51) Within an application, the programmer may state conditions that they assumed to be true at a particular point. These conditions, called assertions, help ensure a program's validity by catching potential bugs and indentifying possible logic errors.

52) Java includes two versions of an assert statement for validating assertions programatically.

53) To enable assertions at run time, use the -ea switch when running the java command.

About the Authors

Dr. Harvey M. Deitel, Chairman and Chief Strategy Officer of Deitel & Associates, Inc., has 43 years experience in the computing field, including extensive industry and academic experience. Dr. Deitel earned B.S. and M.S. degrees from the Massachusetts Institute of Technology and a Ph.D. from Boston University. He worked on the pioneering virtual-memory operating-systems projects at IBM and MIT that developed techniques now widely implemented in systems such as UNIX, Linux and Windows XP. He has 20 years of college teaching experience, including earning tenure and serving as the Chairman of the Computer Science Department at Boston College before founding Deitel & Associates, Inc., with his son, Paul J. Deitel. He and Paul are the co-authors of several dozen books and multimedia packages and they are writing many more. With translations published in Japanese, German, Russian, Spanish, Traditional Chinese, Simplified Chinese, Korean, French, Polish, Italian, Portuguese, Greek, Urdu and Turkish, the Deitels' texts have earned international recognition. Dr. Deitel has delivered hundreds of professional seminars to major corporations, academic institutions, government organizations and the military.

Paul J. Deitel, CEO and Chief Technical Officer of Deitel & Associates, Inc., is a graduate of the MIT's Sloan School of Management, where he studied Information Technology. Through Deitel & Associates, Inc., he has delivered Java, C, C++, Internet and World Wide Web courses to industry clients, including IBM, Sun Microsystems, Dell, Lucent Technologies, Fidelity, NASA at the Kennedy Space Center, the National Severe Storm Laboratory, Compaq, White Sands Missile Range, Rogue Wave Software, Boeing, Stratus, Cambridge Technology Partners, Open Environment Corporation, One Wave, Hyperion Software, Adra Systems, Entergy, CableData Systems and many other organizations. Paul is one of the most experienced Java corporate trainers having taught about 100 professional Java training courses. He has also lectured on C++ and Java for the Boston Chapter of the Association for Computing Machinery. He and his father, Dr. Harvey M. Deitel, are the world's best-selling Computer Science textbook authors.