Exception handling during the development of Java EE

j2ee| Process | exception handling has 3 types of exceptions in Java:





1. A check-type exception, which inherits from Excetpion, is required to be checked during compilation, and if the exception is throw, then the throws that must be displayed after the method in which the exception is located must also be caught where the method is invoked. Otherwise, the compiler throws an exception. The remoteexception in the EJB is such an exception.





2. A Run-time exception, which is an exception that occurs during the run, inherits from RuntimeException, which is not checked at compile time, such as nullpointerexcetpion,numberformatexception.





3. System error, usually the JVM is thrown when the exception, such as OutOfMemoryError, such an exception in the development of Java EE is not concerned about.





in the development of Java EE, the check type abnormality is abused so that after a while the programmer himself can not read such an exception,. Inside the package of these error messages is what to use, More frightening is that there are a lot of useful information can not be found. Like SqlException and remoteexception, we don't need to encapsulate the exception, which is only useful for our debugger, and it's a "system error" for the customer. Just. Exception handling has a simple principle, when do you need to encapsulate your own check-type exceptions? is that you are very aware of the use of this exception, such as user input username and password to log in, but the user name and password do not match, you have to define a check-type exception, the client by capturing the exception, The corresponding error is then fed to the customer. Other errors or anomalies that are not expected of themselves, such as SqlException, are encapsulated into ejbexception, and the EJB container appends its information to remoteexception. This way, the client captures the remoteexception and writes it to the system log, which is easy to debug.





about error codes, there are two types of error codes that are generally fed back to customers:





1. Application-level errors that are caused by the customer's own reasons, such as incorrect input information and no permission to manipulate the feature. For such cases, the system should give the user a clear hint.





2. System-level exceptions, such as "not connected to the server", "Server Busy", "not connected to the database", "System error," The result of this error to the customer is not able to operate, then the following play should be the system administrator and system developers to play.





personally feel that the check-type exception corresponds to an application-level error, and the run-time exception corresponds to a system-level exception.