Exception handling in SCA Java

[rick rineholt <cr...@yahoo.com>]

I may have missed it but what is our error and
exception handling strategy in 
java Tuscany?  Working on some of the demos I can say
that we really need to 
strive hard to provide the context that these happen. 
As an end user I think 
I'd really like any exceptions that happens in the
context of a System / 
Subsystem/ Module/ Component/(fragment?) has something
in the message that 
identifies these. Personally I'd go as far as the
naming the SCDL file these are 
associated with.

How about  at runtime and exceptions generated in user
written components ? 
Will we have a separate log that will identify the
component/module/subsystem?

 From the code I see it looks like there is a a lot
there to make Tuscany scale 
well, and if we foresee complex and very large
composite configurations if we 
can't identify the location of exceptions by the SCA
artifacts for the end user 
I think that will be a major real world useablity issue.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Exception handling in SCA Java

[Jim Marino <jm...@myromatours.com>]

On Apr 5, 2006, at 6:45 PM, rick rineholt wrote:

> I may have missed it but what is our error and
> exception handling strategy in
> java Tuscany?  Working on some of the demos I can say
> that we really need to
> strive hard to provide the context that these happen.
> As an end user I think
> I'd really like any exceptions that happens in the
> context of a System /
> Subsystem/ Module/ Component/(fragment?) has something
> in the message that
> identifies these. Personally I'd go as far as the
> naming the SCDL file these are
> associated with.
We had written up a policy on this that I can't seem to find on the  
web site but is in my sandbox under docs (I also remember sending a  
couple of emails to the list a while back).  It is a little out of  
date but still accurate. Generally all but a few exceptions (there  
are exceptions, no pun intended)  thrown in the runtime must extend  
TuscanyRuntimeException or TuscanyException. One of the exceptions to  
this rule is when an SCA API is called, we throw the SCA exception.   
TRE and TE provide context information and methods for adding  
additional context information as the exceptions are propagated.  I  
don't think we should provide the SCDL file name since some  
configuration may not come from a SCDL file, and more importantly,  
all SCDL files are named the same. The way things work now, we try  
and provide the aggregate context name and any additional context  
identifiers which generally map to component name. This should be  
enough to trace a problem down, e.g. "exception was thrown by the Foo  
component which is in the Bar module component" .
>
> How about  at runtime and exceptions generated in user
> written components ?
> Will we have a separate log that will identify the
> component/module/subsystem?
>
Maybe I'm not following the scenario here but user written components  
should log and handle exceptions in most cases. I would expect if  
they do not do so properly, they just get propagated up the stack and  
the deployment environment either vomits the error to the client and/ 
or logs it. There are a couple of situations where Tuscany may wrap  
exceptions thrown in user components, such as an exception thrown by  
a method marked with @Init.  We also wrap exceptions thrown by a  
target when invoked through a wire and then unwrap the exception when  
the
invocation unwinds back to the client. In both cases, our normal  
exception handling policy is followed. Other than this, I don't think  
the runtime should do much else, such as logging, since either client  
code or the deployment platform should make those decisions.

>  From the code I see it looks like there is a a lot
> there to make Tuscany scale
> well, and if we foresee complex and very large
> composite configurations if we
> can't identify the location of exceptions by the SCA
> artifacts for the end user
> I think that will be a major real world useablity issue.
>
Yes agreed. I think the current exception handling mechanisms are in  
place to deal with this. Code can trap exceptions and add additional  
context as they are propagated.

> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>