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);

...

?

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

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?

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.

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.

Thank you for info! I will redesign.