azp: vscode ext collect all errors of independent subtemplates at the same time

[ChristopherHX]

Currently only on template file error path is shown in the error message

[bryanbcook]

I think it would make sense to adapt/wrap the results of the template expansion so that we aren't allowing Exceptions from the .NET space to bubble up into the extension.

eg

{
  "errorMessages": [
      {
          "file": "<path>",
          "pos": { "line": 1, "col": 2 },
          "message": "parameter is missing..."
      }
  ],
  "files": [
      {  "repo": "owner/repo@ref", "file": "path" }
  ]
  "finalYaml": "// encoded yaml",
}

[ChristopherHX]

I currently consider to use the following pattern /\(([^\\\)\(]+)\)([^\\\)\(]+) \(Line: (\d+), Col: (\d+)\): ([^\\\)\(]+)/g to parse the template errors in the extension out of an exception message.

Some of my code uses new Exception("<message>") or other exception types to provide user input errors, as long this didn't change I prefer to pass all errors.

The stacktrace and exception type can be removed from Release builds. The stacktrace polutes the error message regex parsing a bit.

[bryanbcook]

In my opinion, a regex is a poor choice for parsing these errors. You have typed objects (TemplateValidationException) that contain well-defined error messages, files and exact file locations.

Best practice is to design a set of application-specific exceptions and trap and handle these appropriately as these represent the expected and valid errors recognized by your application. These Exceptions should not bubble up to end users.

Anything else is an unplanned or unhandled exception (NullReference, ArgumentNull, etc). These unhandled exceptions typically represent flaws in the application control logic, and almost always represent a defect. There are also some exceptions you simply cannot handle (OutOfMemory, StackOverflow).

[ChristopherHX]

In my opinion, a regex is a poor choice for parsing these errors.

You are right, I already saw misparsed errors...

You have typed objects (TemplateValidationException) that contain well-defined error messages, files and exact file locations.

We would have to change these TemplateValidationError(s) classes, before we can do that file location is converted to string before it is stored. (I copied them in 2021 from actions/runner)

The errors need refactoring, a lot of errors have missing file information / wrong ones.

For example an error should get multiple file locations if we are in a nested template, currently you need to read the trace log to find how you got to the error

[ChristopherHX]

I'm not shure where error file locations from yaml parser with idx location are coming from. Can these be stored in object form? Did a quick search and couldn't yet find an answer in the source code.

[bryanbcook]

...and exact file locations...

My mistake, I thought the TemplateValidationException had the FileId, Line and Column as properties. These details are captured in the error message and calculated here. Reading the file details from the Exception.Message instead of the stack trace is less likely to present issues.

[ChristopherHX]

Nothings planned for this issue, independent error reporting of multiple included templates has been implemented. Still using regex...