@Anybody interested
Piru wrote:
I believe in this case you're lucky to have "close" enough environment in both the code nuking and the catch part. However, I'm pretty confident this isn't always the case.
So I believe to be fully functional in all cases this thing requires some sort of state saving and restoring. For simple cases this could well be enough, however.
I made some extensive tests of the idea. The behaviour is exactly as you would expect from manually checking for the problem and throwing a appropriate exception. The only difference is that you don't actually have to check for condition, thereby removing conditional tests for every case.
There is an impact, as Piru predicted, on things like holding locks etc. However, the impact is exactly the same as if you throw an exception manually from within a piece of code. As with all error handling strategies, anything that can be handled locally obviously should be. By using automatically created and destroyed auxilliaries (see earlier post with the Lockable class example) that handle locking (lock on create, unlock on destruct) within a function, this problem is totally mitigated from C++ side.
An exception can occur deep within the OS, which is a different prospect, but simply restoring the trap within deep implementation of an OS realisation of a class is more than sufficient to handle this case.
So the end result is, for high level code the technique works, and works well. When dealing with much lower level code, which naturally should be restricted only to implementation details, the handling can be safely deactivated to prevent any ill effects from diverting the flow of execution at the point of failure.
