On Thu, May 28, 2009 at 3:59 PM, kelvin goodson <[email protected]> wrote:
> In running the OASIS tests in the 2.x otests directory, I've been
> having trouble ensuring what seems like a "successful" outcome is
> really successful when the expected outcome is an exception being
> thrown. The OASIS test infrastructure requires only that tests which
> should fail do fail; a very weak postcondition which can be met by
> all kinds of circumstances, including bad setup of eclipse projects.
> There are plans afoot for the test infrastructure to permit an
> implementation to enforce tighter postconditions, and I was hoping to
> be able to begin tabulating more precisely the nature of the
> exceptions that Tuscany will throw for each test case that expects
> failure. I was also hoping that there was some generic postcondition I
> could enforce, such as all encountered Exceptions being derived from a
> given Tuscany Exception parent class, but that's not the case. I was
> wondering if there have been discussions concerning exceptions,
> exception handling etc. that might help me understand what Tuscany
> should be throwing in any given circumstance.
>
> Kelvin
>
Hi Kelvin
Good questions. The code at present isn't very clean with regard to
how exceptional conditions are handled.
There are two types of things that can happen when you read a
contribution into the runtime
1/ A user error - The user has got something wrong in the contribution
and could reasonably be expected to fix it and try again
2/ A system error - Some systematic error (out of memory?) has
occurred that will likely required operator assistance.
I don't think that we have been very consistent to date so this would
be a good opportunity to tidy this up in 2.x before going on the
assign errors to negative test cases
The approach in 1.x throughout the read/resolve/build phases was to
register user errors with the monitor so that they can be analyzed
later and reported to the user. There are some issues currently, in no
particular order
A/ often the messages don't have enough contextual information. We
should be reporting
Contribution Name/Path to failing artifact/the error and what might
be done to fix it
where path to failing artifact could be composite name/component
name/service name etc..
B/ we tried an approach where processing continues after the first
error is found in an attemp to report as many problems in a composite
as possible. Not all of the code takes accoun of this and so results
can be unpredictable. We should probably stop at the first SEVERE
error rather than trying to continue
C/ There is a mix of exception and monitor calls in the various
processing classes that need rationalizing as we are fixing A and B
D/ We need to define a generic user exception to report the contents
of the monitor
E/ We need to define/identify which system exception(s) can be reported
F/ We could do with deconstructing the 1.x itest/validation and, if
possible, put the tests with the modules that report the error.
G/ There a monitor utilities for reporting errors and warnings
repeated all over the place that could do with being consolidated in
one convenient place.
Simon
