assert semantic change proposal

Sean Kelly via Digitalmars-d digitalmars-d at puremagic.com
Wed Aug 6 17:22:14 PDT 2014


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.


More information about the Digitalmars-d mailing list