计算机科学与技术毕业设计论文外文翻译-高效的java异常类处理

计算机科学与技术毕业设计论文外文翻译-高效的java异常类处理内容摘要：

proach to using Java exceptions. When the amount of exception handling code threatens to outweigh everything else, you can tell that munication between team members has broken down (or was never there in the first place), and everyone is treating exceptions their own way. The results of ad hoc exception handling are very predictable. If you ask team members why they threw, caught, or ignored an exception at a particular point in their code, the response is usually, I didn39。 t know what else to do. If you ask them what would happen if an exception they are coding for actually occurred, a frown follows, and you get a statement similar to, I don39。 t know. We never tested that. You can tell if a Java ponent has made effective use of Java exceptions by looking at the code of its clients. If they contain reams of logic to figure out when an operation failed, why it failed, and if there39。 s anything to do about it, the reason is almost always because of the ponent39。 s error reporting design. Flawed reporting produces lots of log and fet code in clients and rarely anything useful. Worst of all are the twisted logic paths, nested try/catch/finally blocks, and other confusion that results in a fragile and unmanageable application. Addressing exceptions as an afterthought (or not addressing them at all) is a major cause of confusion and delay in software projects. Exception handling is a concern that cuts across all parts of a design. Establishing architectural conventions for exceptions should be among the first decisions made in your project. Using the Java exception model properly will go a long way toward keeping your application simple, maintainable, and correct. Challenging the Exception Canon What constitutes proper use of Java39。 s exception model has been the subject of considerable debate. Java was not the first language to support exceptionlike semantics。 however, it was the first language in which the piler enforced rules governing how certain exceptions were declared and treated. Compiletime exception checking was seen by many as an aid to precise software design that harmonized nicely with other language features. Figure 1 shows the Java exception hierarchy. In general, the Java piler forces a method that throws an exception based on including that exception in the throws clause in its declaration. Also, the piler verifies that clients of the method either catch the declared exception type or specify that they throw that exception type themselves. These simple rules have had farreaching consequences for Java developers worldwide. The piler relaxes its exception checking behavior for two branches of the Throwable inheritance tree. Subclasses of and are exempt from piletime checking. Of the two, runtime exceptions are usually of greater interest to software designers. The term unchecked exception is applied to this group to distinguish it from all other checked exceptions. Figure 1 ： Java exception hierarchy I imagine that checked exceptions were embraced by those who also valued strong typing in Java. After all, pilerimposed constraints on data types encouraged rigorous coding and precise thinking. Compiletime type checking helped prevent nasty surprises at runtime. Compiletime exception checking would work similarly, reminding developers that a method had potential alternate outes that needed to be addressed. Early on, the remendation was to use checked exceptions wherever possible to take maximum advantage of the help provided by the piler to produce errorfree software. The designers of the Java library API evidently subscribed to the checked exception canon, using these exceptions extensively to model almost any contingency that could occur in a library method. Checked exception types still outnumber unchecked types by more than two to one in the J2SE API Specification. To programmers, it seemed like most of the mon methods in Java library classes declared checked exceptions for every possible failure. For example, the package relies heavily on the checked exception IOException. At least 63 Java library packages issue this exception, either directly or through one of its dozens of subclasses. An I/O failure is a serious but extremely rare event. On top of that, there is usually nothing your code can do to recover from one. Java programmers found themselves forced to provide for IOException and similar unrecoverable events that could possibly occur in a simple Java library method call. Catching these exceptions added clutter to what should be simple code because there was very little that could be done in a catch block to help the situation. Not catching them was probably worse since the piler required that you add them to the list of exceptions your method throws. This exposes implementation details that good objectoriented design would naturally want to hide. This nowin situation resulted in most of the notorious exception handling antipatterns we are warned about today. It also spawned lots of advice on the right ways and the wrong ways to build workarounds. Some Java luminaries started to question whether Java39。 s checked exception model was a failed experiment. Something failed for sure, but it had nothing to do with including exception checking in the Java language. The failure was in the thinking by the Java API designers that most failure conditions were the same and could be municated by the same kind of exception. Faults and Contingencies Consider a CheckingAccount class within an imaginary banking application. A CheckingAccount belongs to a customer, maintains a current balance, and is able to accept deposits, accept stop payment orders on checks, and process ining checks. A CheckingAccount object must coordinate accesses by concurrent threads, any of which may alter its state. Chec。