Better runtime errors. This is not for merging, only for validating the idea.

[boryanagoncharenko]

Disclaimer This PR is not for merging, the tests do not pass and only one code scenario works. The idea is to validate a possible approach for improving runtime errors.

Current state of runtime errors Currently, if an error occurs at runtime (e.g. the user supplied string as input to the ask command but an int is expected in the next statement #2790), the python error leaks and it is usually too cryptic for the Hedy user. Sometimes we handle the matter in the transpiler (example) but this approach is not great because 1) the error message is hardcoded in English and 2) we are putting presentation logic in the transpiler.

Suggestion Maybe we could achieve better results by making the front end call an endpoint to translate of the runtime error. When skulpt returns an error, we already make a call to the backend to log this error. The current suggestion adds a second call to get a translation. The transpiler will need to provide some information regarding the expectations which could then be used by the translating endpoint to create a good error message containing the actual problem and a suggestion for a fix.

Here are the steps to execute the scenario implemented by the PR:

• Compile the babel translations and run Hedy locally
• Go to level 8 and execute this code:

n is ask 'how many times?'
repeat n times
    print 'Hello everyone'

• Input a text value, e.g. abc
• Now enjoy a nice error, which shows you what went wrong and gives a suggestion how to fix it. Just like a transpile-time error.

If you don't want to run it, this is how it looks:

How to test While this idea improves runtime errors it also could impose issues. Consider and provide feedback on the following:

• This will add time to the one of the most crucial flows in Hedy - running programs. Making the error depend on a call might lead to unpleasant results if the call takes too long. How long is the acceptable time to wait for a better error? We could add a timeout or we could try to think of improvements. Or shall we implement this, measure it and take action if it not acceptable?
• This will increase and probably complicate the transpiled code and specifically the unit tests. I think the unit tests maintenance could be tackled with abstracting transpiled code.

[arjank]

Marked as draft because it's for "validating the idea".

[boryanagoncharenko]

As discussed with Felienne, closing this PR. Ideally, we would not make a call to the backend just for the translation, but we would use the existing mechanism for translating messages in the FE.