Summary of exception handling in Java EE project (an article I have to read)

Why talk about exception handling in J2EE projects? Many java beginners may want to say, "exception handling is not try... Catch... Finally? Everyone can!". I think so when I first learned Java. How to define the corresponding exception class in a multi tier J2EE project? How to handle exceptions at each layer of the project? When is an exception thrown? When are exceptions recorded? How should exceptions be recorded? When do I need to convert a checked exception to an unchecked exception, and when do I need to convert an unchecked exception to a checked exception? Should exceptions be rendered to the front page? How to design an exception framework? This paper will discuss these problems.

1. Java exception handling

In procedural oriented programming language, we can determine whether the method executes normally by return value. For example, in a program written in C language, if the method executes correctly, it returns 1 If there is an error, 0 is returned. In the application developed by VB or Delphi, when an error occurs, we pop up a message box to the user.

We can't get the details of the error through the return value of the method. Maybe because methods are written by different programmers, when the same type of error occurs in different methods, the returned results are inconsistent with the error information.

Therefore, the Java language adopts a unified exception handling mechanism.

What is an exception? Errors that occur at runtime that can be captured and processed.

In the Java language, exception is the parent class of all exceptions. Any exception extends to the exception class. Exception is equivalent to an error type. If you want to define a new error type, extend a new exception subclass. The advantage of using exceptions is that you can accurately locate the source code location that causes the program error and obtain detailed error information.

Java exception handling is implemented through five Keywords: try, catch, throw, throws and finally. The specific exception handling structure is defined by try catch…. Finally block. The try block stores Java statements that may have exceptions. Catch is used to catch and handle exceptions. The finally block is used to clear the unreleased resources in the program. It does not manage how the code of the try block returns. Finally blocks are always executed.

A typical exception handling code

You can see the advantages of Java's exception handling mechanism:

The errors are classified uniformly by extending the exception class or its subclasses. Thus, the same error may have different error information in different methods. When the same error occurs in different methods, you only need to throw the same exception object.

Get more detailed error information. Through the exception class, you can give the exception more detailed and more useful error information to users. To facilitate the user to track and debug the program.

Separate the correct return result from the error message. It reduces the complexity of the program. The caller does not need to know more about the returned result.

Force the caller to handle exceptions to improve the quality of the program. When a method declaration needs to throw an exception, the caller must use try The catch block handles exceptions. Of course, the caller can also let the exception continue to be thrown one level up.

2. Checked exception or unchecked exception?

Java exceptions are divided into two categories: checked exceptions and unchecked exceptions. All inherited Java All exceptions of lang.exception belong to checked exceptions. All inherited Java All exceptions of lang.runtimeexception belong to unchecked exceptions.

When a method calls a method that may throw a checked exception, the exception must be caught, processed or re thrown through the try... Catch block. Let's look at the declaration of the createstatement () method of the connection interface.

perhaps

(of course, resources such as connection and satement need to be closed in time. This is just to illustrate that the checked exception must force the caller to catch or continue to throw.)

Unchecked exceptions are also called runtime exceptions. Usually, runtimeexceptions represent exceptions that the user cannot recover, such as unable to obtain a database connection, unable to open a file, etc. Although users can catch unchecked exceptions just as they handle checked exceptions. However, if the caller does not catch the unchecked exception, the compiler will not force you to do so.

For example, a code that converts characters to integer values is as follows:

The method signature of parseInt is:

Numberformatexception will be thrown when the passed in parameter cannot be converted to the corresponding integer. Because numberformatexception extends to runtimeException, it is an unchecked exception. Therefore, there is no need to try... Catch when calling the parseInt method

Because Java does not force the caller to catch or throw up unchecked exceptions. So programmers always like to throw unchecked exceptions. Or when you need a new exception class, you are always used to extending from runtimeException. When you call some of its methods, if there is no corresponding catch block, the compiler will always let you pass. At the same time, you don't need to know what exceptions will be thrown by this method. This seems like a good way, but it is far from the real intention of Java exception handling. And it will mislead the programmer who calls your class, because the caller doesn't know under what circumstances to handle exceptions. The checked exception can clearly tell the caller what exception to handle when calling this class. If the caller does not handle it, the compiler will prompt and cannot compile. Of course, how to deal with it is up to the caller to decide.

Therefore, Java recommends that people use checked exceptions in application code. As we mentioned in the previous section, the good thing about using exceptions is that it can force the caller to handle the exceptions that will be generated. Checked exceptions are used as standard in official JAVA documents such as Java Tutorial.

Using checked exception should mean that there are many try... Catch in your code. After writing and processing more and more try... Catch blocks, many people finally began to doubt whether the bottom of checked exception should be used as a standard.

Even Bruce Eckel, the author of the famous thinking in Java, changed his mind. Bruce Eckel even advocates the use of unchecked exceptions as a standard. And publish an article to test whether the checked exception should be removed from Java. Bruce Eckel said: "when there is a small amount of code, the checked exception is undoubtedly a very elegant idea and helps to avoid many potential errors. However, experience shows that the result is just the opposite for a large amount of code."

For a detailed discussion of checked exceptions and unchecked exceptions, please refer to

《java Tutorial》 http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html