I personally prefer not to continue after a serious error like infinite loops or runtime exception. An infinite loop, for example, might take 5 to 10 sec of Jobe server time before it times out. If it does that for every test, the job could take a minute or so of Jobe server CPU time, and too many of those might actually overload the server. It's also very annoying for the student to have to wait for the entire run to complete before they can proceed. My preferred approach is to let students see the first error, and then let them fix that (for a penalty) and continue.
However, that's just my take and several other people have asked this question, so there's clearly a need.
CodeRunner treats any output to stderr as a runtime error and aborts testing. There's no way to switch off this behaviour, so you have to catch the exceptions or stderr output and redirect the output to stdout. With write-a-function questions in Python or other interpreted languages this can be done fairly easily in the template but with write-a-program questions or with compiled languages like C/C++ you have to use the template as a control program to manage the whole compile-and-run process. If you want to handle infinite loops, you will also need to use some sort of watchdog timer to ensure that your control program gets back control before the entire job times out.
If you're asking write-a-program questions, you can follow the approach described here
. You would need to change the compile command to C++ and you will need to change the line that runs the code to limit the execution time and to redirect stderr to stdout. Something like the following (untested) could replace the two lines starting output = subprocess.check_output(...):
run_result = subprocess.run(["./prog"], text=True, capture_output=True, timeout=2)
print(run_result.stderr + "\n" + run_result.stdout)
You will also need to catch subprocess.TimeoutExpired exceptions.
If you're not a Python programmer you can implement all this functionality in C++, but it's harder (for me, anyway).
Most of our custom question types at the University of Canterbury use scripted control of the sort described above. The initial complexity is worth the cost, because you then have complete control of the process and can, for example, do extra style checks on student-supplied code, ban undesired constructs, catch specific errors, etc.
I can provide further help if necessary, but you might prefer not to have all this extra complexity.