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".
