com.bea.p13n.exceptions
Class ApplicationException

java.lang.Object
  java.lang.Throwable
      java.lang.Exception
          com.bea.p13n.exceptions.ApplicationException

All Implemented Interfaces

Serializable

Direct Known Subclasses:

AdvisorException, AlreadyExistsException, AuthenticationException, ConfigurableEntityCreateException, ContentException, EntityNotFoundException, ExpressionException, GroupAlreadyExistsException, InvalidArgumentException, InvalidGroupnameException, InvalidPasswordException, InvalidUsernameException, MailServiceException, OperationNotSupportedException, ProfileNotFoundException, PropertySetParseException, PropertyValidationException, com.bea.p13n.rules.internal.RuleException, UserAlreadyExistsException

public abstract class ApplicationException
extends Exception

An abstract base class designed to be extended by a given subsystem or service. It provides exception-chaining functionality that allows for printing a chained stack trace. The ApplicationException is the superclass of those exceptions created as a result of an application-specific condition that may occur. For example, an application may experience a business logic failure which needs to be communicated back to the caller, and alternative programmatic action may be chosen to compensate for the failure. It is HIGHLY RECOMMENDED that subclasses provide the same constructors that are present in this class in order to maintain the highest degree of compatibility with this API. Although not enforced by this class, it is STRONGLY RECOMMENDED that the message argument set in the constructor originate from the WLS message catalog and not be hard-coded. For example:

   public static final MySubsystemExceptionTextFormatter myFormatter = 
         new MySubsystemExceptionTextFormatter();
   . . . 
   throw new MySubsystemException( myFormatter.MyExceptionMessage( arg0, arg1) );
 

Subclasses should contain data attributes pertaining to the failed condition such that a precise, meaningful message can be conveyed to the caller. A good check is to examine the exception message. If the message has placeholders representing application objects, those application objects should probably exist as attributes in the given exception class.

See Also

Serialized Form

Constructor Summary

ApplicationException()

ApplicationException(String message)

ApplicationException(String message, Throwable cause)

ApplicationException(Throwable cause)

Method Summary

Methods inherited from class java.lang.Throwable

fillInStackTrace, getCause, getLocalizedMessage, getMessage, getStackTrace, initCause, printStackTrace, printStackTrace, printStackTrace, setStackTrace, toString

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

Constructor Detail

ApplicationException

public ApplicationException()

ApplicationException

public ApplicationException(String message)

Parameters

message - String representing the Exception message

ApplicationException

public ApplicationException(String message,
                            Throwable cause)

Parameters

message - String representing the exception message

cause - Throwable object representing the caused exception

ApplicationException

public ApplicationException(Throwable cause)

Parameters

cause - Throwable object representing the causing exception