Fix docs error for custom error messages

[kristianmandrup]

See custom_errors page in features list.

The labels for both API interfaces are mistakingly IParserErrorMessageProvider, should be:

• IParserErrorMessageProvider
• ILexerErrorMessageProvider

Would also be nice with a short guide/overview rather than having to parse and understand the intricacies of the code...

// ----------------- Custom Error Provider ------------
const myErrorProvider = {
    buildMismatchTokenMessage: function(options) {
        // override mismatch tokens errors when Bravo is expected
        // Imagine Bravo is a terminating Token such as "SemiColon"
        if (options.expected === Bravo) {
            return "expecting Bravo at end of " + options.ruleName
        } else {
            // fallback to the default behavior otherwise.
            return defaultParserErrorProvider.buildMismatchTokenMessage(options)
        }
    },

    /// ... more methods
}

Extend parse and pass in the custom error provider as errorMessageProvider option in the call to super.

class CustomErrorsParser extends Parser {
    constructor(input) {
        super(allTokens, {
            // passing our custom error message provider
            errorMessageProvider: myErrorProvider
        })

Somehow the mis_match rule will use the buildMismatchTokenMessage to build the message... ???? Some kind of naming convention? Would be nice with an explicit map to customize this I think.

const errorMap = {
  mis_match: buildMismatchTokenMessage
}

Looks very "magical" currently and not well documented.

    constructor(input) {
        const $ = this

        $.RULE("mis_match", () => {
            $.CONSUME(Alpha)
            // we will call this rule with [Alpha, Charlie] to produce a mismatch Token Exception.
            $.CONSUME(Bravo)
        })

[bd82]

Incorrect Labels

Thanks for pointing it out. It has been fixed.

Would also be nice with a short guide/overview rather than having to parse and understand the intricacies of the code...

Yes a guide would be good, but I have not gotten around to it for a long while now...

• Document custom error messages support and labels #675

Accepting pull requests. 😄

Somehow the mis_match rule will use the buildMismatchTokenMessage to build the message... ???? Some kind of naming convention? Would be nice with an explicit map to customize this I think.

There is no special linking buildMismatchTokenMessage would be used in all cases
a mismatchTokenException is thrown regardless of which rule we are in.
And the other custom error methods are the same,
linked to an error type, not to a specific rule.

[bd82]

I am closing this because the remaining work is in #675

[kristianmandrup]

Great to see these fixes and docs keep getting better. Would love to see a mention/reference about gates in the main tutorial guide.

Also, hope to see an initial version of CST with location info soon, that is not optimized but works. Cheers!

[bd82]

Great to see these fixes and docs keep getting better.

It helps when issues are opened about those, my POV regarding docs is different
than most end users, so it helps if people point out where extra clarification is needed 👍

Also, hope to see an initial version of CST with location info soon, that is not optimized but works. Cheers!

@clement26695 from JHipster has started working on it here:

• implement logic to compute node location information #943

You should be able to override 2-4 methods in your parser instance to achieve an un-optimized solution without waiting for an official feature.