Sthx::Apply::Err

Returns the index of the byte where the error occured.

Returns the character that caused the error, or is immediately near the place where the error occurred.

Returns the index of the character where the error occured.

Appends a human-readable representation of this error to io.

• filename may optionally specify the filename to display.
• styled enables or disables styled output.
• readout enables or disables code readout (showing the line where the error occurred)
• bb is the bounding box of the readout. The first number is the maximum number of columns to display, and the second number is the maximum number or rows (lines) to display. Lines surrounding the line where the error occurred are shown.

TODO: bounding box width is currently not implemented.

Same as humanize but returns a string instead of appending to an IO.

Computes and returns a {line, column} tuple with the line and column where the error occured, counting both from 1. You are advised to cache the result.

Returns the source string that was used during application.

Returns the Tree built so far.

As this is an error, this is the last valid Tree object, which doesn't always mean a valid tree from your point of view. From your point of view it is partially valid, or underfilled. That is, if let's say a key matched, but there was an error in the value, the error's tree will contain the key but (obviously) not the value node.

If you put enough precautions in place you'll be able to do error- resilient evaluation/analysis. Note though, that currently parsing past the error is not implemented. So this isn't true error-resilience yet (if continuing to parse in a bad state ever was error resilience in the first place...)

Obviously enough this functionality needs lots of tinkering and testing if you really plan to rely on it. It might not produce the results you expect as it is highly sensitive to the way your grammar is structured, especially on the dependency of some rules on others.