On Wednesday, 6 August 2014 at 22:01:47 UTC, Walter Bright wrote:
On 8/6/2014 12:34 PM, Sean Kelly wrote:
There is no facility for forcing a clean termination of another
thread.
Understood - so the only option is to force an unclean
termination.
So in all cases, it seems like what we should be doing is call
exit(1) or the equivalent and forego any attempt at cleanup.
Otherwise an assertion failure in a spawned thread would be
handled even more strongly than in the main thread.
Alternately, if we build on std.concurrency we could have the
next call to receive throw a FatalError or something to force it
to terminate. But there's no telling how long this would be. I
assume you prefer the forceful route.
Let me emphasize that when an assert trips, the program has
failed. It is in an invalid, unknown, indeterminate state from
that moment forward.
I think in many cases the scope of possible invalid states can
actually be determined given a reasonable understanding of the
program. For example, if a thread within a @safe app encounters
an error, it might be possible to assert that the damage does not
extend beyond the limits of data referenced by the thread. But I
do appreciate the desire to not deal lightly with detected logic
errors so I won't push the point.
Use enforce() for errors that are anticipated and cleanly
recoverable, not assert().
Given what I said above, I'm inclined to say that enforce()
should be used by in contracts and the like rather than assert(),
and to save assert() for the situations where I'm certain there's
absolutely nothing to be done. However, I think of enforce() to
be more for run-time problems that might be corrected by trying
again later with the same input. I'll have to give this some
thought.
