Postmortem: Template unittests are bad & you shouldn't catch Error

[Ali Çehreli]

On 10/22/20 1:38 PM, Adam D. Ruppe wrote:

 > On Thursday, 22 October 2020 at 20:23:49 UTC, Ali Çehreli wrote:
 >> 1) Thread entry functions should catch and report any Throwable.
 >> Otherwise, main thread will see only a timeout and stack trace of the
 >> worker will lost.
 >
 > Worth remembering catching actually loses valuable information when
 > running in a debugger and/or with core dumps enabled.
 >
 > If you did want to do this, at a minimum it would have to honor the
 > DRT-trapExceptions value.

Once again, thank you. But I tried this and it seems to be effective 
only on the main thread.

So, in case of multiple threads, assuming that a thread threw Error, I 
don't know any better solution than the following.

The options are progressively more wishful. In theory, options beyond 
'a' should not be attempted but option 'a' is not practical nor safe.

a) Don't do anything. I think this choice is horrible because

- The rest of the threads would still be continuing with presumably 
invalid program state.

- Nobody would know that a thread has died.

- Nobody would know the stack trace when Error was thrown.

b) Catch Error in the worker thread and call abort() immediately. Note: 
In the strictest sense, even calling abort() should not be attempted but 
this thinking is madness because otherwise the rest of the program would 
be continuing with "invalid state."

c) Same as 'b', but do stderr.writeln(err) before abort(). This way, we 
*may* have an idea of what happened but in a safety-critical 
application, we may be killing a human instead of printing anything.

d) Catch Error and send it as a message to the main thread and let the 
main thread do one of the above. Even though this feels the cleanest, I 
don't see any benefit in doing this over the others.

Over the years, I've been a part of many error management strategy 
discussions on these forums and elsewhere I still don't know what to do. 
For example, there are safety-critical programs out there that can't 
even abort. The thinking is that instead of leaving a machine in its 
"invalid state", which may kill humans, there is always a better way of 
degrading the machine's operations to do something safer. For example, 
in the case of autonomous driving, slowing down the vehicle slowly and 
parking on the side of the road may be better than aborting at 120kph on 
the highway.

Always a fascinating discussion...

Ali