improve feedback on runtime errors

[bmesuere]

Example: https://dodona.ugent.be/nl/submissions/966755/

• I assume that the error message on top of the page is a general error. If so, it would be clearer if a small message was shown explaining this, i.e. "The following error occurred while running your code".
• Why is this error shown on top and not in the feedback table?
• Why is the error shown twice?
• In the feedback table, it is not clear what's the meaning of return (unprocessed) or exception (unprocessed). I assume the test failed (because of the red color), but it is not clear from the table if this was because of missing/incorrect output or an exception.

Original issue by @bmesuere on Sat Sep 09 2017 at 16:58.

[pdawyndt]

@bmesuere

• before individual unit tests are run, the submitted source code is compiled and executed in an interactive (REPL) environment, in which the successive tests are run; however, if a compilation error occurs, or if a runtime exception is thrown while running the submitted source code, a top-level message is displayed, and none of the unit tests is executed (this is the meaning of the unprocessed status of the unit tests
• showing compilation/runtime errors during initial execution of submitted source above the feedback table seems logical, if feedback table itself is reserved for reporting unit tests; alternative could be to show message in a separate tab, but I don't think this would make it clearer
• second message is only visible for staff, not for students, and shows the entire stack trace; the student version only shows a cleaned-up version of the stack trace, where the parts of the call stack that refer to the judge code is removed; this should finally be removed from the judge, but is currently in there for easy inspection to see of the cleanup is done as it should
• the status unprocessed of a test means that the unit test has not been evaluated (e.g. in case of compilation/runtime error while running submitted code, or upon time-limit exceeded); see this issue in the Dodona repo where I suggest to support the unprocessed status in Dodona; as such all colors in an unprocessed test case would be different from correct/wrong test cases (e.g. grey color)

Here's an updated version with an additional message and an explicit indication of the staff version of the message:

Original comment by @pdawyndt on Sun Sep 10 2017 at 17:40.