You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by kelvin goodson <kg...@thegoodsons.org.uk> on 2009/05/28 16:59:08 UTC
exceptions
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
Re: exceptions
Posted by Simon Laws <si...@googlemail.com>.
On Fri, May 29, 2009 at 11:18 AM, kelvin goodson
<ke...@gmail.com> wrote:
> Simon,
> thanks, that gives me some ideas where to look. I think I'll begin
> by looking at a,b and c, with one eye on d and g.
>
> Kelvin
>
> 2009/5/28 Simon Laws <si...@googlemail.com>:
>> On Thu, May 28, 2009 at 3:59 PM, kelvin goodson <kg...@thegoodsons.org.uk> 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
>>
>
Ok, great Kelvin. When you've started to get your mind round it let's
bash it out here. If you need any help or a run through of how the
code works at the moment let me know.
Simon
Re: exceptions
Posted by kelvin goodson <ke...@gmail.com>.
Simon,
thanks, that gives me some ideas where to look. I think I'll begin
by looking at a,b and c, with one eye on d and g.
Kelvin
2009/5/28 Simon Laws <si...@googlemail.com>:
> On Thu, May 28, 2009 at 3:59 PM, kelvin goodson <kg...@thegoodsons.org.uk> 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
>
Re: exceptions
Posted by Simon Laws <si...@googlemail.com>.
On Thu, May 28, 2009 at 3:59 PM, kelvin goodson <kg...@thegoodsons.org.uk> 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