More helpful error messages

[arosien]

Rather than the user having to scroll through the mess of the backend debugger log in the Terminal, we can send the exception message along with the event type back to the extension, which then logs it in a distinct "Daffodil" Output tab.

The user then clicks the "show logs" to switch to that tab.

The current errors are:

• ErrorEvent.UnhandledRequest: if the backend receives a type of request it doesn't understand
• ErrorEvent.LaunchArgsParseError: if the backend can't parse the launch args when starting a DAP session
• ErrorEvent.RequestError: the backend had a problem executing a request; this includes runtime exceptions from Daffodil like schema compilation
• ErrorEvent.SourceError: used during an experiment for having backend-provided source files, not used currently
• ErrorEvent.UnexpectedError: used when a watch expression can't be evaluated; this error seems to be redundant and could perhaps be merged with RequestError

The PR doesn't display the particular the error type, only the underlying message. The user can look at the regular logs for the details.

Fixes #931.

[lrbarber]

What types of error messages are affected by this change?

[arosien]

What types of error messages are affected by this change?

Excellent question. They are:

• ErrorEvent.UnhandledRequest: if the backend receives a type of request it doesn't understand
• ErrorEvent.LaunchArgsParseError: if the backend can't parse the launch args when starting a DAP session
• ErrorEvent.RequestError: the backend had a problem executing a request; this includes runtime exceptions from Daffodil like schema compilation
• ErrorEvent.SourceError: used during an experiment for having backend-provided source files, not used currently
• ErrorEvent.UnexpectedError: used when a watch expression can't be evaluated; this error seems to be redundant and could perhaps be merged with RequestError

The PR doesn't display the particular the error type, only the underlying message. The user can look at the regular logs for the details.

[hdalsania]

@arosien How do we test this PR?

[shanedell]

@arosien For future notice, normally 2 green check marks are desired before merging in a PR.

[arosien]

@arosien For future notice, normally 2 green check marks are desired before merging in a PR.

there were 2: @hdalsania and @shanedell

[stevedlawrence]

I don't think @hdalsania is a Daffodil committer or PMC. Although we definitely appreciate reviews from non-committers/PMC, and doing so is a good way to show commitment to the project and earn the merit to become one, their votes do not count towards the required 2 +1's ASF requires merge. The green checkmark is a good indication of this since non-committers only get a grey checkmark when they approve a PR.

[arosien]

ah, sorry all. it's difficult for me to tell the difference between the green and grey checks, they look quite similar to my eyes.

i think the "Changes Approved" summary at the bottom accurately shows the green check count, i'll make sure to refer to that

On Thu, Mar 21, 2024 at 4:16 AM Steve Lawrence @.***> wrote:

I don't think @hdalsania https://github.com/hdalsania is a Daffodil committer or PMC. Although we definitely appreciate reviews from non-committers/PMC, and doing so is a good way to show commitment to the project and earn the merit to become one, their votes do not count towards the required 2 +1's ASF requires merge. The green checkmark is a good indication of this since non-committers only get a grey checkmark when they approve a PR.

— Reply to this email directly, view it on GitHub https://github.com/apache/daffodil-vscode/pull/991#issuecomment-2011976936, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAHTO57UMNFZ3SNWWN5EJTYZK6Q5AVCNFSM6AAAAABEYOP5FGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJRHE3TMOJTGY . You are receiving this because you were mentioned.Message ID: @.***>