Simon Laws wrote:
...snip
If we are going for consistency then I think 1-1 is not an option
because of runtime situations that don't fit this pattern. I think
we are likely to need a mixture of 1-2 and 1-3 depending on the code
execution path.
So the third category of confusion should of course have been
3 Where are the errors being reported
3-1 read
3-2 resolve
3-3 build
3-4 activate
3-5 start
3-6 runtime
3-7 stop
I think we have been considering 3-1 to 3-5 and 3-7 as one and
distinct from 3-6. At the moment I believe we currently only use the
monitor in 3-1 to 3-3.
I think it will be
a big step backwards in usability if only one error in the static
artifacts can be detected at a time.
I would happily replace a list of several unclear error s for one
clear error. but maybe we just have to agree to disagree on this. To
move forward it not going to worry me if we deal with this once we
have the context question under control.
I agree 100% about the undesirability of a list of several unclear errors.
When I come across examples of unclear diagnostics for error cases,
I create and apply a fix (see TUSCANY-2698 and TUSCANY-3172 as examples).
What I am suggesting is the following:
1. The first diagnostic should always be clear and complete.
2. If it is not possible to continue because the runtime is damaged,
we should stop immediately.
3. If it is possible to continue without risk of further unclear
cascading errors, we should continue.
3. If it is not possible to continue without risk of further unclear
cascading errors, we should stop immediately.
I think there is agreement on 1, 2 and 4. Perhaps the disagreement
is on whether 3 is possible and practical.
Simon
2-2 would be far too much work. 2-4 doesn't have sense to me as we
should always be producing context when we have addressed issue 1.
I agree and raised this specifically as there was a suggestion
previously on the thread that the lack of context was a valid reason
for not performing subsequent processing which seemed a bit arbitrary
to me.
Simon
