Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Enhance error detection at parsing time #4210

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

Closed
pekkaklarck opened this issue Jan 30, 2022 · 5 comments
Closed

Enhance error detection at parsing time #4210

pekkaklarck opened this issue Jan 30, 2022 · 5 comments

Comments

@pekkaklarck
Copy link
Member

pekkaklarck commented Jan 30, 2022

Robot's parser detects many errors already at the parsing time, but there are also many syntax errors that are only detected at the execution time. A problem with detecting errors only at the execution time is that they aren't reported to tools like editor plugins that use Robot's parser. We should thus move error detection to parser as much as possible. This includes at least these cases:

  • Empty test and keyword.
  • END, ELSE, ELSE IF, EXCEPT or FINALLY when there is no matching parent element like IF or TRY.
  • RETURN used in test. Fixed already in RF 5.0.
  • BREAK/CONTINUE outside loops. Fixed already in RF 5.0.
  • RETURN/BREAK/CONTINUE in FINALLY. Fixed already in RF 5.0.

We also have a similar problem that some of the error situations detected by the parser are not detected as early as they could be. For example, having IF with more than one condition is detected by the parser when the parsing model is validated, but the underlying tokens do not get ERROR type. This is a problem if only using tokens (i.e. when using get_tokens, not get_model) and also when using the model it would be more convenient if invalid tokens could be easily detected. This problem occurs at least in these cases:

  • IF, ELSE IF and WHILE with more than one condition.
  • ELSE, END, BREAK, CONTINUE, TRY and FINALLY with values.
  • AS with invalid variable or with more than one variable.

Because these latter errors are detected by the parser, only a bit late, I don't consider this limitation as bad as the problem with the earlier errors.

@yanne
Copy link
Member

yanne commented Mar 2, 2022

These three points are covered already in 5.0:

  • RETURN used in test.
  • BREAK/CONTINUE outside loops.
  • RETURN/BREAK/CONTINUE in FINALLY.

@pekkaklarck
Copy link
Member Author

pekkaklarck commented Sep 27, 2022

After ffa0d4e syntax errors are reported during execution using raise DataError(msg, syntax=True). All such usages are listed below and some of these could probably be detected already at parsing time:

src/robot/running/bodyrunner.py
101:                error = DataError(data.error, syntax=True)
301:            raise DataError('FOR loop has no loop values.', syntax=True)
348:                error = DataError(data.error, syntax=True)
442:            error = DataError(syntax_error, syntax=True)
510:                    raise DataError(data.error, syntax=True)

src/robot/running/namespace.py
289:            raise DataError('Keyword name cannot be empty.', syntax=True)
291:            raise DataError('Keyword name must be a string.', syntax=True)

src/robot/running/model.py
196:                    raise DataError(self.error, syntax=True)
218:                    raise DataError(self.error, syntax=True)
240:                    raise DataError(self.error, syntax=True)

@pekkaklarck
Copy link
Member Author

Need to take a closer look at this and submit concrete issues about errors that could be detected earlier.

@mkorpela mkorpela changed the title Enhance errror detection at parsing time Enhance error detection at parsing time Jan 11, 2023
yanne added a commit that referenced this issue Jan 18, 2023
@yanne
Copy link
Member

yanne commented Jan 18, 2023

Fixed empty name and keyword validation in 4376e59

yanne added a commit that referenced this issue Mar 1, 2023
Also make runtime changes to create a separate Error object in test/keyword
bodies and sserialize this in XML and show in logs.

Relates to #4210
yanne added a commit that referenced this issue Mar 1, 2023
Also make runtime changes to create a separate Error object in test/keyword
bodies and sserialize this in XML and show in logs.

Relates to #4210
yanne added a commit that referenced this issue Mar 2, 2023
Also make runtime changes to create a separate Error object in test/keyword
bodies and sserialize this in XML and show in logs.

Relates to #4210
yanne added a commit that referenced this issue Mar 2, 2023
Also make runtime changes to create a separate Error object in test/keyword
bodies and sserialize this in XML and show in logs.

Relates to #4210
yanne added a commit that referenced this issue Mar 2, 2023
These errors will now cause failures in running the tests, so the
console messages are redundant.

Relates to #4210
yanne added a commit that referenced this issue Mar 3, 2023
yanne added a commit that referenced this issue Mar 6, 2023
yanne added a commit that referenced this issue Mar 6, 2023
Also make runtime changes to create a separate Error object in test/keyword
bodies and sserialize this in XML and show in logs.

Relates to #4210
yanne added a commit that referenced this issue Mar 6, 2023
These errors will now cause failures in running the tests, so the
console messages are redundant.

Relates to #4210
yanne added a commit that referenced this issue Mar 6, 2023
@yanne
Copy link
Member

yanne commented Mar 14, 2023

We decided to leave this part for a later stage:

`We also have a similar problem that some of the error situations detected by the parser are not detected as early as they could be. For example, having IF with more than one condition is detected by the parser when the parsing model is validated, but the underlying tokens do not get ERROR type. This is a problem if only using tokens (i.e. when using get_tokens, not get_model) and also when using the model it would be more convenient if invalid tokens could be easily detected. This problem occurs at least in these cases:

IF, ELSE IF and WHILE with more than one condition.
ELSE, END, BREAK, CONTINUE, TRY and FINALLY with values.
AS with invalid variable or with more than one variable.
Because these latter errors are detected by the parser, only a bit late, I don't consider this limitation as bad as the problem with the earlier errors.`

Other enhancements listed in the original post are now fixed.

@yanne yanne closed this as completed Mar 14, 2023
yanne added a commit that referenced this issue Mar 18, 2023
Also make runtime changes to create a separate Error object in test/keyword
bodies and sserialize this in XML and show in logs.

Relates to #4210
yanne added a commit that referenced this issue Mar 18, 2023
These errors will now cause failures in running the tests, so the
console messages are redundant.

Relates to #4210
yanne added a commit that referenced this issue Mar 18, 2023
yanne added a commit that referenced this issue Mar 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants