Better handling of exceptions thrown by the application in `qne experiment run`

[brunorijsman]

qne experiment run does not handle exceptions thrown by the application well:

• The experiment does not terminate immediately when the application throws the exception; instead the experiment run hangs for 60 seconds and then terminates with a TimeoutExpired exception

• The output of qne experiment run (which actually does contain the call stack of the root cause exception hidden inside of it) is very difficult to read because all newlines have been replaced by /n (see example output below)

• In the case of an error, the qne experiment run command still returns status code $? zero, instead of a non-zero status code. This makes it difficult to check for failures in scripts

To reproduce: throw some exception (e.g. x = 1/0 in the application code)

Example output:

Error encountered while running the experiment
{'exception': 'TimeoutExpired', 'message': 'Call to simulator timed out after 60 seconds.', 'trace': 'Traceback (most recent call last):\n  File "/Users/brunorijsman/git-personal/quantum-internet-hackathon-2022/venv/bin/netqasm", line 8, in <module>\n    sys.exit(cli())\n  File "/Users/brunorijsman/git-personal/quantum-internet-hackathon-2022/venv/lib/python3.8/site-packages/click/core.py", line 1130, in __call__\n    return self.main(*args, **kwargs)\n  File "/Users/brunorijsman/git-personal/quantum-internet-hackathon-2022/venv/lib/python3.8/site-packages/click/core.py", line 1055, in main\n    rv = self.invoke(ctx)\n  File "/Users/brunorijsman/git-personal/quantum-internet-hackathon-2022/venv/lib/python3.8/site-packages/click/core.py", line 1657, in invoke\n    return _process_result(sub_ctx.command.invoke(sub_ctx))\n  File "/Users/brunorijsman/git-personal/quantum-internet-hackathon-2022/venv/lib/python3.8/site-packages/click/core.py", line 1404, in invoke\n    return ctx.invoke(self.callback, **ctx.params)\n  File "/Users/brunorijsman/git-personal/quantum-internet-hackathon-2022/venv/lib/python3.8/site-packages/click/core.py", line 760, in invoke\n    return __callback(*args, **kwargs)\n  File "/Users/brunorijsman/git-personal/quantum-internet-hackathon-2022/venv/lib/python3.8/site-packages/netqasm/runtime/cli.py", line 344, in simulate\n    simulate_application(\n  File "/Users/brunorijsman/git-personal/quantum-internet-hackathon-2022/venv/lib/python3.8/site-packages/squidasm/run/multithread/simulate.py", line 89, in simulate_application\n    result = mgr.run_app(app_instance, use_app_config=use_app_config)\n  File "/Users/brunorijsman/git-personal/quantum-internet-hackathon-2022/venv/lib/python3.8/site-packages/squidasm/run/multithread/runtime_mgr.py", line 204, in run_app\n    results[name] = future.get()\n  File "/usr/local/Cellar/python@3.8/3.8.14/Frameworks/Python.framework/Versions/3.8/lib/python3.8/multiprocessing/pool.py", line 771, in get\n    raise self._value\n  File "/usr/local/Cellar/python@3.8/3.8.14/Frameworks/Python.framework/Versions/3.8/lib/python3.8/multiprocessing/pool.py", line 125, in worker\n    result = (True, func(*args, **kwds))\n  File "/Users/brunorijsman/git-personal/quantum-internet-hackathon-2022/qne_adk/teleport/teleport_experiment/input/app_sender.py", line 17, in main\n    x = 1/0\nZeroDivisionError: division by zero\n'}

[platelminto]

Hey Bruno, thanks for opening the issue!

Point 2: We currently have a fix for this issue mostly in-place (see closed PR here) - we're just waiting on pushing it to PyPI. Should be resolved by the end of the week.

Point 1: Though the exception is now thrown & printed (see above), it will still hang. In normal usage, one can Ctrl+C once they see an appropriate exception printed, but this will be a problem for scripts. Unfortunately, this is an issue deeper in the actual simulator code, so we cannot fix it in QNE-ADK. We will try and fix the core issue, but there's no guarantees that this will be soon. I will see if I can find a workaround (maybe by looking at stderr).

Point 3: I'll open an internal ticket for this, shouldn't be too difficult to fix.

[brunorijsman]

One more thing: if the application throws an exception, the log files are not produced. In other words, any messages written to an app_logger don't appear in any log file. This (combined with the fact that the output of print statements don't appear anywhere) makes it nearly impossible to debug the sequence of events that lead up to the exception.