Entire data object is included in output on ParseError, when ParseErrorAction is set to anything other than ThrowError

[andersjonsson]

Template: "Hello {Name"

That template is clearly missing an end curly brace

Smart.Format("Hello {Name", new { Name = "Anders Jonsson", City = "Stockholm"})
//Result: Exception

So far so good.

But after setting Smart.Default.Settings.ParseErrorAction I get an unexpected output.

Smart.Default.Settings.ParseErrorAction = SmartFormat.Core.Settings.ErrorAction.Ignore;
Smart.Format("Hello {Name", new { Name = "Anders Jonsson", City = "Stockholm"})
//Result: "Hello { Name = Anders Jonsson, City = Stockholm }Name"

Smart.Default.Settings.ParseErrorAction = SmartFormat.Core.Settings.ErrorAction.MaintainTokens;
Smart.Format("Hello {Name", new { Name = "Anders Jonsson", City = "Stockholm"})
//Result: "Hello { Name = Anders Jonsson, City = Stockholm }Name"

Smart.Default.Settings.ParseErrorAction = SmartFormat.Core.Settings.ErrorAction.OutputErrorInResult;
Smart.Format("Hello {Name", new { Name = "Anders Jonsson", City = "Stockholm"})
//Result: "Hello { Name = Anders Jonsson, City = Stockholm }Name"

That doesn't seem like the intended behavior. Am I missing something?

[axunonb]

Hi,

Looks like for ParseErrorAction only ErrorAction.ThrowError was implemented.
With other settings, the formatter is still called, leading to unexpected results like in your sample.

So, yes, the other error actions could be implemented. I'm a bit in doubt, whether anything else than ThrowError makes sense for parsing errors, though.

When implemented, in your example, the results would look like this:

MaintainTokens: Hello {Name

Ignore: (an empty string)

OutputErrorInResult: The format string has 1 issue:
Format string is missing a closing brace
In: "Hello {Name"
At: -----------^

ThrowException:
Well, throws...

What do you think?

[andersjonsson]

I think your proposed result for MaintainTokens makes sense.
I personally want a behavior where SmartFormat does what it can with the input and leaves the rest the way that it was.

Regarding Ignore I would expect the result to be Hello , but I see your point. A case could even be made for Hello Name, but I think that's a stretch.

[axunonb]

Regarding Ignore I would

This kind of Ignore would also be close to MaintainTokens, and goes away from "don't show the problem to possible end users".
What about proceeding the way mentioned above? I think I could finish the implementation tomorrow. Would you be able to provide the required unit tests on top? Then I would open a new branch for that.

[andersjonsson]

What about proceeding the way mentioned above?

I see you point. Sounds good!

Would you be able to provide the required unit tests on top?

Sure thing

[axunonb]

Sure thing

Great! Should go into ParserTests.cs

[andersjonsson]

Implementing the tests now.

When I use the template Hello, I'm {Name from {City}
and the input new { Name = "John", City = "Oklahoma" }

MaintainTokens give me Hello, I'm {Name from {City}. I was expecting Hello, I'm {Name from Oklahoma

And the parser error says "SmartFormat.Core.Parsing.ParsingErrors : The format string has 3 issues:
Invalid character in the selector, Invalid character in the selector, Invalid character in the selector"

With Hello, I'm {Name it says "SmartFormat.Core.Parsing.ParsingErrors : The format string has 1 issue:
Format string is missing a closing brace". A more correct description of the problem IMHO.

Is it possible to make the parser leave the current expression on the first error, so that it can successfully parse correct expressions later in the string?

[axunonb]

"Invalid character in the selector" is connected to the parser settings. AlphaNumeric selectors must be enabled, then this error should vanish.

…

________________________________ Von: Anders Jonsson <notifications@github.com> Gesendet: Mittwoch, 17. Februar 2021 10:14 An: axuno/SmartFormat <SmartFormat@noreply.github.com> Cc: Norbert Bietsch <nb@axuno.net>; Comment <comment@noreply.github.com> Betreff: Re: [axuno/SmartFormat] Entire data object is included in output on ParseError, when ParseErrorAction is set to anything other than ThrowError (#143) Implementing the tests now. When I use the template Hello, I'm {Name from {City} and the input new { Name = "John", City = "Oklahoma" } MaintainTokens give me Hello, I'm {Name from {City}. I was expecting Hello, I'm {Name from Oklahoma And the parser error says "SmartFormat.Core.Parsing.ParsingErrors : The format string has 3 issues: Invalid character in the selector, Invalid character in the selector, Invalid character in the selector" With Hello, I'm {Name it says "SmartFormat.Core.Parsing.ParsingErrors : The format string has 1 issue: Format string is missing a closing brace". A more correct description of the problem IMHO. Is it possible to make the parser leave the current expression on the first error, so that it can successfully parse correct expressions later in the string? — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#143 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACOH2MHOIDPKWW5XT4ZBC5DS7N3FXANCNFSM4XUJNOSQ>.

[axunonb]

Is it possible to make the parser leave the current expression on the first error, so that it can successfully parse correct expressions later in the string?

Short answer: no
Long answer: would require a major redesign, and it also would be difficult to evaluate the rest of the string if there is an error in it before

[andersjonsson]

Short answer: no
Long answer: would require a major redesign, and it also would be difficult to evaluate the rest of the string if there is an error in it before

Oh, that's too bad. Now I see why you didn't think anything else than ThrowError made sense. I guess I should have had a better example in my initial description.

I'll send a PR with the tests shortly

[axunonb]

Thanks a lot. Will be able to have a deeper look tonight (CET).