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
