digitalmars.D.learn - Throwable catching
- Alexandr Druzhinin (31/31) Sep 28 2013 catching Throwable is wrong. But is it wrong if I used it in separate
- Jonathan M Davis (11/48) Sep 28 2013 It's just as wrong to catch Throwable there is at is anywhere. If you do...
- Alexandr Druzhinin (5/15) Sep 28 2013 Just to clear - in my case child thread processes parent commands like a...
- monarch_dodra (22/27) Sep 28 2013 It most certainly doesn't "reset bad application state".
- Dicebot (10/15) Sep 28 2013 Error generally means unrecoverable application issue. It can
- Alexandr Druzhinin (1/1) Sep 28 2013 Thank you for info! I will redesign.
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
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
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 DavisJust 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
"monarch_dodra" <monarchdodra gmail.com> 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
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