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

[Brad Roberts]

On 7/11/2018 5:45 AM, crimaniak via Digitalmars-d 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.

 From experience, on multiple teams with extremely large fleets of 
machines running some of the largest websites and services, one of the 
most powerful tools that helped us go from good up times (2-4 9's) to 
excellent up times (4-6 9's) was from using application exiting asserts 
in production.  Yes, you kill the app.  You exit as fast and often as 
the errors occur.  You know what happens?  You find the bugs faster, you 
fix them even faster, and the result is solid software.

One caveat that's affects this is delivered vs managed software. The 
rules and patterns are drastically different if you're burning software 
on cd and selling it through stores with no path to make updates, but 
that's less and less the case every day.

When you're afraid of your software and afraid to make changes to it, 
you make bad choices.  Embrace every strategy you can find to help you 
find problems as quickly as possible.