Throwable catching

[monarch_dodra]

On Saturday, 28 September 2013 at 12:26:37 UTC, Alexandr
Druzhinin wrote:
> Just to clear - in my case child thread processes parent 
> commands like a worker and every loop iteration isn't 
> correlated with others before and after so I thought that just 
> new iteration resets bad application state caused by Error - I 
> was wrong?

It most certainly doesn't "reset bad application state".

Chances are, if your loops are 100% non correlated, you *might*
get away with it, since you won't depend on the previous state.
However, you *will* have leaked destructors, maybe leaked some
memory, leaked file some handles, left some ressources locked, 
transactions open but neither failed nor passed etc...

Keeping the "program" (or in this case, thread) simply isn't a
good idea.

*Ideally* you should catch the error, send a high priority "I
failed your command, and am about to die" message to the parrent
thread, and then die. The parent thread should then deal with the
error (log that one of the jobs did not work, for example), and
then re-launch a fresh new thread.

But even then you'll have no
guarantees on the state of global shared variables. Also, I'm
unsure if when a thread dies, if its resources are relinquished
back to the OS, or if the entire program needs to die for that?
I think the entire program needs to die for that.

Long story short, an error means the program is *crashing*.
Keeping it going in such circumstances is just not a good idea.