The term 'application exception' is used to describe an exception that
is potentially recoverable and which does not cause a transaction to be
rolledback.
Runtime exceptions can be thrown and will force transaction rollback.
They will get converted to RemoteException by the container.
Laird Nelson wrote:
>
> The 1.1 specification speaketh thusly:
>
> An application exception is an exception defined in the throws clause
> of a method of the enterprise Bean's home and remote interfaces,
> other than the java.rmi.RemoteException.
>
> Then it is writ as follows:
>
> An application exception must not be defined as a subclass of the
> java.lang.RuntimeException, or of the java.rmi.RemoteException.
>
> Finally, it declaimeth:
>
> Enterprise bean business methods use application exceptions to inform
> the client of abnormal application-level conditions, such as
> unacceptable values of the input arguments to a business method.
>
> I tend to be an obsessive type of person and so consequently when left
> to my own devices I do lots of argument checking (to simulate
> design-by-contract, sort of). I throw lots of IllegalArgumentExceptions
> in normal Java code to indicate *unrecoverable and unacceptable* values
> of input arguments to a method (recoverable exceptions should be checked
> of course). I like the fact that they are runtime exceptions, because
> typically, contrary to popular opinion, they cannot actually be
> recovered from--it usually indicates a bug in the software. To put it
> another way, IllegalArgumentExceptions are discovered by the developer
> and should never show up in production code.
>
> I still think of these as application exceptions--and the specification
> snippets above seem to me to confirm that view.
>
> It looks like the EJB1.1 specification says that if I want to perform
> argument checking where I'd normally throw an IllegalArgumentException
> or (one of my own creations) a NullArgumentException (a
> java.lang.RuntimeException subclass), I have to throw a checked
> exception instead. This would put a huge burden on callers, it seems to
> me, since argument checking could happen in lots of places. Also, since
> the kind of argument checking I'm talking about emulates assertions, any
> exception that is thrown resulting from one of these argument checks is
> by definition unrecoverable. So the client will simply turn around and
> either exc.printStackTrace() or some other moderately useless "recovery"
> tactic.
>
> What are other people doing to detect, for example, illegal null
> arguments, or other illegal argument values, since you can neither throw
> NullPointerException nor IllegalArgumentException nor
> IllegalStateException, since all are examples of
> java.lang.RuntimeException? Or should I simply ignore all this and
>
> Cheers,
> Laird
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
