-
Notifications
You must be signed in to change notification settings - Fork 14
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
Ignore errors parsing slicec JSON output #4044
Conversation
{ | ||
// Messages from stdout | ||
var jsonDoc = System.Text.Json.JsonDocument.Parse(singleLine); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this variable still needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we first check that the line (whitespace stripped) begins and ends with {
and }
instead of just ignoring all Json exceptions. Otherwise it might not be obvious if we break something?
catch (JsonException) | ||
{ | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I agree, blindly eating all JsonExceptions feels a little dangerous to me...
@@ -109,27 +109,23 @@ protected override string GenerateFullPathToTool() | |||
/// </summary> | |||
protected override void LogEventsFromTextOutput(string singleLine, MessageImportance messageImportance) | |||
{ | |||
Console.WriteLine(singleLine); | |||
if (messageImportance == MessageImportance.Low) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be better to just have a check at the top here, where if the first character (or maybe non-whitespace character?) isn't {
, just immediately return, instead of invoking the JSONParser.
We could still keep the exception handling centralized in the parser though, except instead of silently eating exceptions, it could Log.LogError(...)
The plug-in should not code defensively against possible bugs in the compiler. I think a better compromise here would be to emit all messages as JSON when The compiler can emit |
Agreed. but no matter what we do, the compiler will sometimes emit non-json stuff, and I don't think we should eat and ignore them. For example, if you pass a bad CLI option, the compiler exits before it even has a chance to properly set json-diagnostics.
Actually, could we go even simpler, and just not emit this summary message at all? |
Yes tools are just going to ignore it.
Right, the ignoring of JSON was just to work around the summary message not being JSON formatted. |
Cool, I'll open a PR for |
See: icerpc/slicec#702 |
With the changes made to the Slice compiler, the original issue should be fixed now. But I still think that this centralized parser is nicer, and worth doing. The only change I would recommend is emitting an error message when we hit an exception in the JSON parsing, instead of ignoring them. |
Fix #4043