www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Throwable catching

reply Alexandr Druzhinin <drug2004 bk.ru> writes:
catching Throwable is wrong. But is it wrong if I used it in separate 
thread to prevent thread dying like:

static void run()
{
	while(true)
	{
		try
		{
			/// do work
			...

			// interacting with parent
			auto msg = receiveTimeout(dur!"msecs"(1),
				(string command)
				{
					/// process command from parent
					if(some_condition_is_true)
						break; // finish
						       // execution
				}
			);
		}
		catch(Throwable t)
		{
			/// some diagnostic message
		}
	}
}

...

auto child = spawn(&run);

...

?
Sep 28 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, September 28, 2013 15:42:43 Alexandr Druzhinin wrote:
 catching Throwable is wrong. But is it wrong if I used it in separate
 thread to prevent thread dying like:
 
 static void run()
 {
 	while(true)
 	{
 		try
 		{
 			/// do work
 			...
 
 			// interacting with parent
 			auto msg = receiveTimeout(dur!"msecs"(1),
 				(string command)
 				{
 					/// process command from parent
 					if(some_condition_is_true)
 						break; // finish
 						       // execution
 				}
 			);
 		}
 		catch(Throwable t)
 		{
 			/// some diagnostic message
 		}
 	}
 }
 
 ...
 
 auto child = spawn(&run);
 
 ...
 
 ?
It's just as wrong to catch Throwable there is at is anywhere. If you do that you'll catch Errors, and Errors are _supposed_ to kill your program. They indicate that something bad enough has occurred that it's better to terminate your program than continue. So, yes, what you're doing will keep the thread from dying, but if you get an Error, you want to shut your program down, not try and keep it running. So, maybe catching Throwable would make sense if you had to then tell the other thread to terminate, but should rethrow the Throwable afterwards and let the thread die. - Jonathan M Davis
Sep 28 2013
parent reply Alexandr Druzhinin <drug2004 bk.ru> writes:
28.09.2013 15:50, Jonathan M Davis пишет:
 It's just as wrong to catch Throwable there is at is anywhere. If you do that
 you'll catch Errors, and Errors are _supposed_ to kill your program. They
 indicate that something bad enough has occurred that it's better to terminate
 your program than continue.

 So, yes, what you're doing will keep the thread from dying, but if you get an
 Error, you want to shut your program down, not try and keep it running. So,
 maybe catching Throwable would make sense if you had to then tell the other
 thread to terminate, but should rethrow the Throwable afterwards and let the
 thread die.

 - Jonathan M Davis
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?
Sep 28 2013
next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Sep 28 2013
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
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?
Error generally means unrecoverable application issue. It can result in undefined behavior if ignored, not matter what is the error locality. For example, out of memory error. Catching Errors may be viable as often as manual vtable patching or any similar low-level unsafe hack. If your worker is _completely_ independent maybe you should just make it separate process that can be simply relaunched upon the Error.
Sep 28 2013
parent Alexandr Druzhinin <drug2004 bk.ru> writes:
Thank you for info! I will redesign.
Sep 28 2013