Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Analysis/validation error philosophy

Hi All,

Well, this deserves some thoughts because somebody would think that "Why the parser must wait until validation phase if we can arise the error during the analyzer phase",  "If we can arise the error in the analyzer phase, why we have to defer the task to the validation phase". However I'm very agree with the following statement:

"However they should only be reported to users once, so since validation may be performed on an independently analysed AST, implementation of error detection during the validation phase should be preferred to implementation during analysis".

+1.

Cheers,
Adolfo.

Ed Willink escribió:
Hi All

https://bugs.eclipse.org/bugs/show_bug.cgi?id=286737 uncovers a variety of Tuple issues that can be dealt with one day.

There is however one philosphical principle we should agree on now.

Some errors can be detected during the analysis or validation phase. However they should only be reported to users once, so since validation may be performed on an independently analysed AST, implementation of error detection during the validation phase should be preferred to implementation during analysis.

Analysis errors are solely for errors that cause the maximally valid generated AST to inadequately express the CST content.

Validation errors are for anything wrong with the AST.

Therefore as code is reviewed some analysis errors need to be removed, and perhaps some validation errors added.

NB. Validation is a relatively recent addition, and the consequences have not been fully resolved.

   Regards

      Ed Willink
*

*

_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


--

Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231 / +34 617 718268

Back to the top