Handling the exceptions in J2EE environment. Part I. (English)

I'd like to consider handling exception in a broader way.
There is 2 type of exceptions - System Exception and Application Exception. System Exception are usually fatal one and they related to the environment where the program run. For example, DB goes down or OutOfMemoryError occurred. Basically it means, that something goes wrong not in the application code but beyond the scope of application. Application Exception are Exceptions that generated by the application. Your application is totally responsible for handling it. One Example can be user put letter in the number field, or some business rule is violated.

Before I will continue I want to make one quick note. All Errors are System Exception (Errors are not intended to be caught by the application in any place). Mostly all RuntimeException are System Exception. Some API defines their "Application Exception" as RuntimeException, though. And there are some scenarios where your application treats RuntimeException as "Application Exception" in order to recover. All Exceptions that you defines in your own application are "Application Exception". All not yours Exception should be "Application Exception" also, but this is not always the case. Generally in the latest case it points out on bad design decision.

System Exception is treated in the following ways:
- let propagate it up to the stack to eventually crash the JVM. This is generally the best strategy with Errors. If OutOfMemoryError occur you can nothing to do with it;
- let propagate it to some high level, log it, and forward the user to the error page. This is generally the best strategy with so-called "unexpected exceptions";
- ignore the exception, wait timeout amount of time and retry or make other recovery strategy. This is rarely used strategy. This means that you work with low level API, if you have to do such things.


Application Exception can be roughly subdivided into two categories:
a) Application Exception that indicates illegal input of the user;
b) Application Exception that indicates violations of the business rule by the user;

a) Application Exception that indicates illegal input of the user.
- the best strategy will be to check all input and to show to the user message with all mistakes he make.
- alternative strategy will be to stop input checking on the first illegal input encounter. Obviously, the former strategy is better, but sometimes you have complex relationship within your input and you don't want to continue to make input validation if something basically goes wrong.

b) Application Exception that indicates violations of the business rule by the user.
Scenario: You make some basic input validation and you start to proceed the user request. Suddenly you discovered that some basic business rule is violated. For example, Customer doesn't exist in the DB.
- the best strategy will be to throw some "Business Exception" to the UI layer that indicates the problem. On practice it doesn't enough because UI has no idea what message should be displayed to the user. Theoretically, UI layer has investigate each exception, each exception has to have enough information, say subscriberId, in order to generate informative message. On practice, message that will be shown to the user is generated in the place where Application Exception occurred and is put on the Exception object itself or in some "global message container".

To be continued.