From the conceptual standpoint there are two fundamental types of exceptions: business exception and non-business exception also known as application exception. Business exceptions occur when business constraints are violated. Application exceptions usually denote flaws in the code (application bugs) or environmental issues such as runtime network and connectivity problems.
Business code developers can define and use any number of concrete business exceptions that inherit from BusinessException.
Application exceptions are physically separated from business exceptions in their own hierarchy parented by AppException. This base exception class provides methods to add full exception context information to be used to diagnose the root cause and circumstances of the error. It also allows handling of application exceptions as a group if needed. AppException is defined as abstract class due to its generic nature. It can not be thrown directly.
The hierarchy of application exception classes is very flat. Concrete application exceptions such as AppArgumentException derive directly from AppException. They are designed as a closed set to represent major root causes of application errors. Each one of them has a well known meaning and should be used accordingly. For example, AppUnsupportedException should only be thrown when an unsupported operation is invoked, AppSecurityException must be thrown when application code allowed access to a forbidden resource, AppArgumentException must be thrown when illegal interface arguments are detected and so on.
Business code developers should not define their own application exception classes. Only well known pre-defined exception classes provided by this package must be used. This will ensure correctness and consistency of the exception handling mechanism developed within the constraints of this exception handling framework. @since 12/15/2004