Making Errors errors

[Atila Neves]

On Friday, 29 January 2021 at 06:03:08 UTC, Andre Pany wrote:
> On Thursday, 28 January 2021 at 17:59:41 UTC, Max Haughton 
> wrote:
>> It has been discussed in a different thread (Making throwing 
>> an error an instant failure, catching Error etc.)
>>
>> I am starting to put together a patch to try out this 
>> behaviour, what do we actually want it to do - should it call 
>> a user specified handler, druntime, c etc.?
>>
>> The rationale makes perfect sense (Errors should indicate 
>> something has gone wrong, the program is in an invalid state - 
>> by definition you cannot recover), but the exact behaviour 
>> must be specified.
>
> What would be the effect of this change on the unit test 
> runners we have (d-unit, silly, unit-threaded)?
> This might break their functionality, as they might catch 
> Errors (unit tests calling assert).
>
> Kind regards
> Andre

Depends on the usage. The reason that unit-threaded catches 
errors is to support unit tests written with asserts, since those 
might even have been written before unit-threaded itself was. The 
idea is to use the custom assertions. My own projects wouldn't be 
affected in the slightest, for instance.