Report Visualization Errors

[4e6]

Pull Request Description

close #1557

Replace VisualisationEvaluationError reply to a binary channel with executionContext/visualisationEvaluationFailed notification. Evaluation error can't be sent as a reply because it is a part of a program execution, that happens asynchronously. It should be a notification with an appropriate context (similar to an expression update notification)

Important Notes

API changes:

• Add a new notification executionContext/visualisationEvaluationFailed

Checklist

Please include the following checklist in your PR:

• The documentation has been updated if necessary.
• All code conforms to the Scala, Java, and Rust style guides.
• All documentation and configuration conforms to the markdown and YAML style guides.
• All code has been tested where possible.

[4e6]

Changelog:

• add: diagnostic info to executionContext/visualisationEvaluationFailed notification and VisualisationExpressionFailed response
• fix: JSON serialization of error payloads

[radeusgd]

Looks good to me

Just please make sure if the tests in ContextRegistryTest and VisualisationOperationsTest are not unnecessarily duplicated - because it seems at first look that some of them are, but I may be missing some nuances.

[radeusgd]

It's not directly relevant to this PR (as this was here before), but I was wondering (and it doesn't seem to be documented) - what is the purpose of this guard? It lets through AbstractTruffleExceptions if the language is null or is Enso - so it specifically ignores errors from different languages, unless language is not set at all.
It seems a bit weird to me, because later we look for the stacktrace so it seems maybe we'd want to have only Enso here? So I'm wondering if it wasn't supposed to be exists instead of forall, but I cannot judge that without documentation that would clarify the intent behind this.

[4e6]

The guard filters only the Enso errors. But currently, getLanguage can only tell the language by the source file, and return null when the error originates in built-in nodes. It means that we need forall to include builtins as well. Builtins cover a significant part of the language, and most of the calls end up there, so we definitely want to support them.

The guard is definitely not obvious, so I'll add a comment there 👍

[radeusgd]

The guard filters only the Enso errors. But currently, getLanguage can only tell the language by the source file, and return null when the error originates in built-in nodes.

So I understand that technically we can get a node with null language that is not from Enso, right? But we have no good way to check that? If yes, if we get such input, do we expect that it could crash or is it safe to execute the rest of the code on it? (And if it is safe, why do we ignore other languages then?)

[4e6]

It should be safe to execute the code on any exception. When the code was written, we only had an Enso and a host (Java) languages, and the idea was to provide the right context and show only stuff related to Enso