Folks 2009/7/27 Simon Nash <[email protected]>
> 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. > Would you care the explain in detail why 1-1 is not an option? I happen to think it is the best option by far. The Monitor is all about handling error reporting in a way that is friendly to SCA, so adding the context there seems simple and natural to me. 1-2 seems like an insane amount of work for little added value. 1-3 is the option I suggest for "foreign" code that we use, where we are not in control of the situation (eg WSDL processors), but that we should catch the exceptions as quickly as possible in our own code, where we can apply the context. Without the context, the exceptions are pretty well useless. > > > 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. > 2-3 makes sense to me in the following way. We will quickly get to understand which problems cause unwelcome cascades of errors - when we find these we simply raise the severity of the problem so that further processing is stopped. The OASIS tests already cause an interesting pile of errors (deliberately) and these can be used as an initial contriibution to working out which problems must be raised to a severity that stops further processing. > > Simon > > Regards >> >> Simon >> >> >> > Yours, Mike.
