Hi Some comments in line....
Simon On Mon, Jun 2, 2008 at 12:30 PM, Mike Edwards < [EMAIL PROTECTED]> wrote: > Folks, > > Thinking about this further, we should I think come up with a common and > consistent model for the handling of problems found during model processing. > > Let me make a proposal or two that folk can throw rocks at if they please: > > - Model processor code should NEVER throw an exception that escapes the > processor code (clearly this would exclude the common JVM nasties like > running out of memory) - doesn't matter what type of exception (1, 2, 3, 4 > in the previous discussions...) How do we define the processor code? Here are a couple of examples. >From stax artifact processor. M read(XMLStreamReader reader) throws ContributionReadException, XMLStreamException; >From composite builder void build(Composite composite) throws CompositeBuilderException; I like the idea of saying NEVER throw an exception but this has to be restricted to well defined processing steps, e.g. those that and extension writer would author (Read, Write, Resolve). As an alternative and in order to maintain the current API such exceptions could be captured in the ExtensibleStAXArtifactProcessor. > > - Throwing exceptions within the scope of the model processor is fine - it > is just that they must all get caught at the boundary of the code. > > - Reporting monitor type messages for the problems found (or perhaps also > for the cases of success too!) should be routine > +1 > > - When problem(s) are encountered, the model processor MUST > > a) Return a model object +1 > > b) Mark that model object as "unresolved" - this should ensure that no-one > tries to instantiate it Without some detailed investigation I can't say if some subsequent resolution phase will treat the unresolved flag correctly. I would hope that the read phase creates errors where appropriate and, subsequent to the read phase the monitor is analysed to see if any errors have been reported. Resolution would generally be prevented if this is the case. > > c) If any of the code DOES try to instantiate some unresolved model object, > we need to go fix that code > +1 > > > We need to think hard about where particular errors should get logged > though. Some errors will belong in the composite model object - eg a < > binding.ws/> element turning up immediately under the <composite/> > element. Others belong in some specific component implementation model > object or binding object.... > Agreed, problems should be reported in the context of the model object within which they are being processed. > > Yours, Mike. > > snip....
