How to handle exceptions during J2EE development

There are three types of exceptions in java:

1. check type exception. This exception inherits from Excetpion, that is, it needs to be checked during compilation. If the exception is throw, throws must be displayed after the method where the exception is located, the exception must also be caught when the method is called. Otherwise, the compiler will throw an exception. remoteException in ejb is such an exception.

2. a runtime exception is a system exception that occurs during the runtime. This exception inherits from RuntimeException, which is not checked during compilation, such as NullPointerExcetpion and NumberFormatException.

3. system errors, such as OutofMemoryError, are thrown when a JVM exception occurs.

During J2EE development, check exceptions were abused so that programmers could not understand and throw such exceptions for a while ,. what are the encapsulated error messages used for? What's more terrible is that a lot of useful information cannot be found. for example, SQLException and RemoteException do not need to be encapsulated. This exception is only useful for debugging programs, but is a "system error" for customers. there is a simple principle for exception handling. When do you need to encapsulate your own checked exceptions? When you are clear about the purpose of throwing this exception, for example, if the user enters the user name and password to log on, but the user name and password do not match, you need to define a check exception, the client captures the exception and sends the error information to the customer. other unexpected errors or exceptions such as SQLException only need to be encapsulated in EJBException. The ejb iner will append its information to RemoteException, in this way, the client captures RemoteException and writes it to the system log, which makes debugging easy.

There are two types of error codes that are generally fed back to the customer:

1. application-level errors. These errors are caused by the customer's own reasons. For example, if the input information is incorrect, you are not authorized to operate the function. in this case, the system should give the user a clear prompt.

2. system-level exceptions, such as "not connected to the server", "server busy", "not connected to the database", and "system error". The consequence of such errors is that they cannot be operated, the following plays should be played by the system administrator and system developers.