Simon Nash wrote:
Mike Edwards wrote:
Simon Nash wrote:
This may be true, but I think it's still useful for the user to know
whether the error stopped all further detection of errors (so there
could be other errors that weren't reported) or whether the error
was caught and allowed further error detection to continue.
Simon
Folks,
In my experience (and I've had a LOT of practice while writing the
OASIS testcases!) many of the more significant errors simply lead to a
cascade of related errors which make it pretty well impossible to work
out anything after the first error, so I rate the value of further
error detection pretty low under these circumstances.
Yours, Mike.
I do understand that in many cases the current code causes this
kind of cascade. This is a serious problem and needs to be fixed.
In cases where it is impossible or impractical to fix it, a fatal
error should be raised. However there are many errors that prevent
execution but do not (or need not) cause this kind of cascade that
makes it impractical to continue with further error detection.
An example of the approach that I have in mind can be found in the
binding-ws-wsdlgen module. When a fatal error that makes further
processing impossible is detected, a WSDLGenerationException is
thrown. If further processing is possible, the diagnostic information
is captured in a WSDLGenerationException object and a monitor problem
containing this WSDLGenerationException object is created.
In the first of these cases, the context information (component and
service/reference) is usually not known at the time the exception is
thrown. There is code in the BindingWSDLGenerator.generateWSDL() method
to catch these exceptions and create a monitor problem for the exception,
together with an additional monitor problem with severity "Warning"
containing the component and service/reference information, which is
always known by the BindingWSDLGenerator.generateWSDL() method.
To generalize this approach, the pattern would be:
If the code detecting the error cannot continue executing or does not
know the context information, it throws an exception containing the
diagnostic information. This exception is caught by higher-level code
that knows the context information. The higher-level code creates a
problem with severity "Error" or "Fatal" for the lower-level exception
and its diagnostic information and another problem with severity
"Warning" containing the context information.
If the code detecting the error can continue executing and knows
the context information, it creates a problem with severity "Error"
containing the diagnostic information and the context information
and then continues executing.
Simon
Please also take a look at the changes in my recent commit r797997.
This introduces a new exception called MonitorRuntimeException which
is used to indicate cases where an error has already been caught and
logged in the monitor and should not be reported again by higher
level processing.
At present the MonitorRuntimeException is always "wrapped" inside a
ServiceRuntimeException for compatibility with existing code that is
expecting a ServiceRuntimeException to be thrown. It might be
possible to eliminate this wrapping in cases where the exception
will always be caught within the Tuscany runtime and will never
"leak out" to application code.
Simon
