Continuing the discussion from Best way to protect application from script bugs:
Just a related note:
Basically, that there is only exception handling to catch issues from scripts is becoming VERY problematic
in high-performance applications that allow editing code inside them. In this situation,
throwing and catching an exception have (very) unpredictable performance which is bothersome
if you need to not make the performance fluctuate too much.
My concrete example is with a game: in this game I sometime need the player to be able to (optionally) write scripts.
However player will necessarily make a lot of mistakes and I need this part of the game to behave like
any compiler+vm. So I report errors, but the fluctuation of performance due to exception handling makes
the experience sometime a bit nasty.
It also totally prevent the use of ChaiScript in contexts where throwing an exception is simply forbidden (a lot of C++ shops and projects).
Also, it does not total sense to throw exeption from ChaiScript in all situations: executing a failing script might be just normal behavior of the code using ChaiScript.
Simply said, it should not be ChaiScript that decide how to dispatch errors resulting from wrong script code.
- I do use exceptions in some places in my game, but only for system failures, not logical ones;
- ChaiScript should totally throw if it’s a problem which is not about the script being wrong (not sure how to fix the boundaries, but syntax issues and not-found names should not be exceptions);
- I’m suggesting that it would be very useful to have an alternative way to evaluate scripts, which does not throw on script that is lexically wrong or access symbols that do not work; but it should not be the default.
I don’t know of a good solution to combine both with and without exceptions (maybe “expected” return type?) but I do consider the throw-on-failure-to-evaluate-script a major performance issue in my project.