Hi,
I've been thinking quite a bit about this, and might as well
share my two cents worth of thinking...
In the interceptor chain exceptions coming from beans and
exceptions coming from the containerinvoker and interceptors
are thrown "in the same channel". This means that it can be
hard to tell if a given exception comes from a bean.
For example, consider an NullPointerException catched in an
interceptor. If the NPE comes from the bean, recovery is
simple: We just setRollbackOnly(), discard the instance and
throws a RemoteException encapsulating the NPE to the client.
But it the NPE comes from the container or one of the
interceptors, the failure is more critical: We should probably
complain louder in this case, and throw a ServerException
towards the client.
The problem, however, is that we have no way to tell for sure
where the exception comes from.
Another problem I see with this is that beans may throw
application exceptions that have to be declared in the
interceptor chain. Since we do not know which application
exceptions the beans may throw, all the invoke() and
invokeHome() methods in the interceptor chain simply declare
that they throw java.lang.Exception.
But this means that the compiler does not complain when an
interceptor programmer forgets to catch an application
exception (like javax.transaction.RollbackException). Instead
this exception is returned to the client as if the bean had
thrown it.
I think that the right solution to these problems is to avoid
throwing bean exceptions (errors, application exceptions and
runtime exceptions) inline with exceptions coming from the
container and interceptor chain.
One way to do this could be to define a new BeanException type
derived from java.lang.Exception that encapsulates the bean
exception and change the invoke() and invokeHome() methods in
the interceptors to only throw BeanException. Such an exception
should probably have a boolean isAppException() method so that
it is easy for interceptors to determine what to do.
I would suggest that the containerinterceptors (last interceptor
in the chain just before the bean) encapsulate exceptions they
get from InvocationTargetExceptions in BeanException.
The container invoker can then unpack the BeanException and
return the right exception to the client.
Comments anyone ?
Best Regards,
Ole Husgaard.
marc fleury wrote:
>
> I agree,
>
> I was looking at this this morning and application and container exceptions
> should be separated in an interceptor. We have a "LogInterceptor" that
> could do this work. It means retooling the exception throwing as container
> or application and work accordingly with the interceptor. For exampel I do
> not want to see the "Jaws" exceptions logged all the time (i.e the "entity
> exists" etc) but the applications ex are important. We can probably do this
> work in the interceptor mentionned, but I need to think some more about
> it... it is a bit "all over the map" right now in the exception throwing and
> handling... streamlining required :)
>
> marc
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Oleg Nitz
> > Sent: Wednesday, September 27, 2000 10:54 AM
> > To: [EMAIL PROTECTED]
> > Subject: [jBoss-User] Exception logging
> >
> >
> > I have noticed that jBoss doesn't log application exceptions, but send
> > them to client. I some places such logging is commented out and marked
> > as "debug". I think it would be more convenient to jBoss users
> > (at least for me and my colleagues) to see the full stack trace on
> > server in addition to the short exception message only that is
> > available on client (since the application exception is wrapped by
> > some RemoteException).
> > Any other opinions?
> >
> > Best regards,
> > Oleg Nitz
> >
> >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
> >
> >
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
