marc fleury wrote:
>
> man we have to stop doing jboss-dev discussion on jboss-user but I will add
> to the fray...
Right, redirecting now...
>
> comments below...
>
> > One way to do this could be to define a new BeanException type
> > derived from java.lang.Exception that encapsulates the bean
>
> Yes the AppException encapsulating the exception Exception is what I was
> thinking of.
>
> > 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.
>
> or we could catch the beanException explicitely.
I agree that using BeanException will fix these problems,
even if the throws clause of invoke() and invokeHome() are
not changed from Exception to BeanException.
But declaring a method to throw an exception as wide as
java.lang.Exception is a possible source of programming
errors: If an interceptor programmer forgets to catch
some exception subclass that should have been declared,
the compiler cannot bark about it, as every exception
is a subclass of Exception.
But the change of the throws clause should only be done
after all code has been changed to use BeanException.
> nope... good for me... wanta take a crack at it?
Problem is that whoever does this have to know all
the interceptors.
I can write a org.jboss.ejb.BeanException class and
help out with the interceptors I know, but if I try
to change all interceptors I am afraid that I might
introduce a lot of bugs.
In a later mail marc fleury wrote:
>
> Thinking some more about it <:)/>
>
> Jaws will throw an exception such as the Create or Finder Exceptions these
> are to be seen as "BeanException", but they can be thrown by Jaws purely in
> CMP.
Yes. The exceptions from CMP persistence should be
wrapped in BeanException.
> I can't think of other plugins that would throw exceptions like that (that
> are "bean" even though they are generated purely in jboss (no instance
> call)...
Nor can I.
> maybe the Tx management ones where we come in and throw "concurent" on
> Sessions for example (see TxInterceptorCMT on sessions)
I don't follow you here. Please explain.
Best Regards,
Ole Husgaard.
