-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor error message #248
Comments
It would be nice if not only the first detected error would be reported. Of course not all types of errors allow that (i.e. syntax errors), but in other cases this would increase the usability. I suppose the mechanism for reporting errors (currently exceptions) would have to be changed to achieve that. |
That's a very good point. We'll probably only be able to continue checking in certain situations. E.g. performing more checks on a model which failed validation already will only produce more spurious errors. OTOH, checking other messages or files after an error in a different message/file could make sense. I'll see what I can do. |
When using an invalid package name for a refinement (say "A.B"), then the expected error is supposed to be something like "A.B is not a valid package name". For refinements, however, the super class is initialized with package * "__REFINEMENT__" f"{flat_name(sdu.full_name)}__{flat_name(pdu.full_name)}__{field.name}__" which produces some convoluted error message mentioning that long internal string. Instead of filtering such situations in the super-class, we now reinitialized the error buffer after initializing the super-class of Refinement, effectively ignoring errors in the ID() constructor. The well-formedness of the package identifier is checked separately. Ref. #248, #285
The fix for #277 was actually not proper, as any contradiction would be flagged as an error. However, as long as there is at least one non-contradictory path, we cannot treat a field condition as contradictory. This problem occurred in the test, but was not discovered as the test was missing a error.propagate() call after message construction. This was noticed when making Message constructors raise exceptions again in the discussion of #285. Ref. #248
We hardly have any source location in our error messages that could be used by and IDE to point the user to the source of an error.
Location
class (file, start line, start column, end line end column)<file>:<line>:<col> <severity> <message>
The text was updated successfully, but these errors were encountered: