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

[crimaniak]

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.