Simon Laws wrote:
I think there are least two issues here that are becoming confused
1 - how to get context information for an error or warning. It think
three suggestions have come out on this thread
1-1 - push/pop it into the monitor
1-2 - change method signatures to pass it down
1-3 - catch thrown exceptions and add it after the fact
2 - should we stop processing after an error
2-1 - yes
2-2 - no, and make all subsequent processing immune to NPE etc.
2-3 - maybe - depending an anaylsis of what code follows
2-4 - maybe - depending an anaylsis of what code follows and on
whether context is available for the first error
I don't mind which answer to question 1 we choose. I started with 1-1
but am happy to accept but 1-2 and 1-3 can also be made to work for
us. I would though argue for consistency. I.e. we try and follow a
single pattern so that, as we develop new function and maintain
existing function, it's clear what we are supposed to do.
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.
My preference for 2 is 2-1. If the consensus is really that we must
continue processing after an error then again I would argue for
consistency and clear rules for the situations under which this
processing is carried out. My second preference would be for 2-3.
For runtime errors we have no choice but to do 2-1. For build-time
errors I have a strong preference for 2-3 because 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.
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.
Simon
Regards
Simon
