On Tue, Apr 15, 2008 at 2:34 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> ant elder wrote: > > > On Tue, Apr 1, 2008 at 4:43 PM, Jean-Sebastien Delfino < > > [EMAIL PROTECTED]> > > wrote: > > > > Simon Nash wrote: > > > > > > Jean-Sebastien Delfino wrote: > > > > > > > > scabooz wrote: > > > > > > > > > > Hi Folks, > > > > > > > > > > > > +1 for warnings when the application is developed. +1 for > > > > > > Errors > > > > > > when > > > > > > you put the application into production. The trick is to know > > > > > > the > > > > > > difference > > > > > > between deployment for UT vs. deployment for real. > > > > > > > > > > > > :-) > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > And the other trick is to allow processing of artifacts with > > > > > errors to > > > > > proceed as well in dev, debug and admin scenarios as well. > > > > > > > > > > For example we should be able to load a composite with errors in > > > > > it, > > > > > in the admin tool, to show these errors to the administrator and > > > > > allow him > > > > > to fix them. > > > > > > > > > > Basically it's the same idea as a with Java editor. A Java editor > > > > > that > > > > > wouldn't allow you to edit Java classes with errors wouldn't be > > > > > very useful > > > > > :) > > > > > > > > > > That means: Not throwing an exception that stops everything on the > > > > > first error, but instead report errors through the monitors that > > > > > we already > > > > > have in various places in the code. > > > > > > > > > > I agree with this statement that everything should not stop on > > > > > the > > > > > > > > > first > > > > error. To reuse my compiler analogy, I wouldn't like the compiler > > > > to > > > > report only one error every time I run it. > > > > > > > > However, this doesn't mean that the faulty class should only produce > > > > a > > > > warning that allows execution to proceed. It should still produce > > > > an > > > > error that causes deployment of this application to fail, but the > > > > error > > > > should be handled in a way that allows it to be batched with other > > > > similar errors to give the user a consolidated failure report. > > > > > > > > Simon > > > > > > > > OK that's fair. I still think that preventing any 'deployment' is > > > too > > > strong, but I can live with it for now and we'll see over time how > > > that > > > evolves. > > > > > > > > > I agree too, thats exactly the type of thing i had in mind. Looks > > like we > > might all be able to reach some consensus after all :) > > > > ...ant > > > > > Trying to catch up on discussions from last week. So what is the > consensus? Is there a summary of it anywhere? > > > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > I'm going to chance my arm here and suggest that the answer to Sebatien's last question is that consensus was reached and that the consensus is that 1. Errors and wranings are recorded as they are encountered 2. Errors and warnings are reported to the user at the point at which makes most sense given the current processing context 3. Further processing subsequent to errors and warnings being reported is at the discretion of the code doing the reporting This sounds a little vague given the detail of the thread. So mapping to the monitor code that is being developed.... 1. Errors and warnings will be lodged with the monitor as problems as processing continues. Exceptions won't be thrown. Processing here covers any processing of user input, i.e. contributions and the artifacts they contain. 2. At some point a phase of processing will be complete, e.g. the contribution has been read, the composite has been built etc.At this point problems would be read from the monitor for display to the user. (currently this will have already happened as our current monitor will just log errors and warnings as it receives them but you can imagine more capable monitors) 3. The controlling logic may look at the errors and warnings it is reporting to the user and prevent further processing occurring. Or it may allow processing to continue. This depends on which bit of processing we are talking about and what errors have been reported. Regards Simon
