Simon Laws wrote:
Kelvin raised TUSCANY-3132 to track any improvements we need to make
to error handling. Now's as good time as any so I kicked off by adding
a couple of sub tasks.
TUSCANY-3150 - we need to report more accurate context along with out errors
This needs us to either maintain context in the manager as we
process the hierarchy or throw exception and catch them on the way up.
+1 for this. Some errors already provide this context information.
This requires careful attention in the exception handling design,
to make sure that the correct context information is available when
the problem report is created.
I'm not sure I understand the "manager" reference. Is this referring
to the domain manager, the monitor, or something else?
TUSCANY-3151 - to stop the runtime when it first encounters an error.
At the moment we accumulate errors as well as warnings and it's just
seems to lead to confusing output
>
Let's fix the confusing output (I presume this is a reference to error
cascading where multiple messages appear for the same error) rather than
removing the valuable capability for users to find and fix multiple
unrelated errors in a single test run.
Not sure if this is absolutely necessary but it seems like it would
simplify things. We could throw the exception from the manager but
we'd have to check that this will bubble to the top successfully so
needs to be considered in the context of 3150
In cases where an immediate stop is needed because the runtime state
is too damaged to continue, I think the code that found the error
should throw a suitable exception to abort processing. Again I'm
not sure what is meant by the "manager" reference.
TUSCANY-3152 - it would seen sensible to have the validation tests
located alongside the functionality they are tested rather than in a
separate itest. The itest is quite difficult to debug as it stands.
+1 for this.
Simon
Any more thoughts on this?
Simon
