Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....

[Joakim]

On Wednesday, 11 July 2018 at 12:45:40 UTC, crimaniak wrote:
> On Tuesday, 10 July 2018 at 22:59:08 UTC, Jonathan M Davis 
> wrote:
>
>>> Or aside from that strawman that RangeError shouldn't be an 
>>> Error even...
>>
>> I suspect that we're going to have to agree to disagree on 
>> that one. ...
>> ...
>> continuing to execute the program is risky by definition. ...
> This error handling policy makes D not applicable for creating 
> WEB applications and generally long-running services. I think 
> anyone who has worked in the enterprise sector will confirm 
> that any complex WEB service contains some number of errors 
> that were not detected during the tests. These errors are 
> detected randomly during operation. And the greatest 
> probability of their detection - during the peak traffic of the 
> site. Do you kill the whole application even in the case of 
> undisturbed memory, with one suspicion of a logical error? At 
> the peak of attendance? To prevent a potential catastrophe, 
> which could theoretically arise as a result of this error? 
> Congratulations! The catastrophe is already here.
> And in the case of services, the strategy for responding to 
> errors must be exactly the opposite. The error should be 
> maximally localized, and the programmer should be able to 
> respond to any type of errors. The very nature of the work of 
> WEB applications contributes to this. As a rule, queries are 
> handled by short-lived tasks that work with thread-local 
> memory, and killing only the task that caused the error, with 
> the transfer of the exception to the calling task, would 
> radically improve the situation. And yes, RangeError shouldn't 
> be an Error.

Sounds like you're describing the "Let it crash" philosophy of 
Erlang:

https://ferd.ca/the-zen-of-erlang.html

The crucial point is whether you can depend on the error being 
isolated, as in Erlang's lightweight processes. I guess D assumes 
it isn't.