-
Error Handling with Exceptions The basic philosophy of Java is that "badly formed code will not be run."The ideal time to catch an error is at compile time, before you even try to run the program.However, not all errors can be detected at compile time. The rest of the problems must be handled at run time through some formality that allows the originator of the error to pass appropriate information to a recipient who will know how to handle the difficulty properly.Improved error recovery is one of the most powerful ways that you can increase the robustness of your code. Error recovery is a fundamental concern for every program you write, but it’s especially important in Java, where one of the primary goals is to create program components for others to use. To create a robust system, each component must be robust. By providing a consistent error-reporting model using exceptions, Java allows components to reliably communicate problems to client code.39184
- 上一篇：应用程序的设计和开发英文文献和中文翻译
- 下一篇：MAP-REDUCE的程序和系统英文文献和中文翻译
The goals for exception handling in Java are to simplify the creation of large, reliable
programs using less code than currently possible, and to do so with more confidence that
your application doesn’t have an unhandled error. Exceptions are not terribly difficult to
learn, and are one of those features that provide immediate and significant benefits to yourproject.
Because exception handling is the only official way that Java reports errors, and it is enforced by the Java compiler, there are only so many examples that can be written in this book
without learning about exception handling. This chapter introduces you to the code that you
need to write to properly handle exceptions, and shows how you can generate your own
exceptions if one of your methods gets into trouble.
C and other earlier languages often had multiple error-handling schemes, and these were
generally established by convention and not as part of the programming language. Typically,
you returned a special value or set a flag, and the recipient was supposed to look at the value
or the flag and determine that something was amiss. However, as the years passed, it was
discovered that programmers who use a library tend to think of themselves as invincible—as
in "Yes, errors might happen to others, but not in my code." So, not too surprisingly, they
wouldn’t check for the error conditions (and sometimes the error conditions were too silly to
check for1 ). If you were thorough enough to check for an error every time you called a
method, your code could turn into an unreadable nightmare. Because programmers could
still coax systems out of these languages, they were resistant to admitting the truth: that this
approach to handling errors was a major limitation to creating large, robust, maintainable
programs.
The solution is to take the casual nature out of error handling and to enforce formality. This
actually has a long history, because 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).
The word "exception" is meant in the sense of "I take exception to that." At the point where
the problem occurs, you might not know what to do with it, but you do know that you can’t
just continue on merrily; you must stop, and somebody, somewhere, must figure out what to
do. But you don’t have enough information in the current context to fix the problem. So you
hand the problem out to a higher context where someone is qualified to make the proper
decision.
The other rather significant benefit of exceptions is that they tend to reduce the complexity of
error-handling code. Without exceptions, you must check for a particular error and deal with