On 7/10/18 6:26 PM, Jonathan M Davis wrote:
> On Tuesday, 10 July 2018 13:21:28 MDT Timon Gehr via Digitalmars-d wrote:
>> On 03.07.2018 06:54, Walter Bright wrote:
>>> ...
>>>
>>> (I'm referring to the repeated and endless threads here where people
>>> argue that yes, they can recover from programming bugs!)
>>
>> Which threads are those?
> 
> Pretty much any thread arguing for having clean-up done when an Error is
> thrown instead of terminating ASAP. Usually, folks don't try to claim that
> trying to fully continue the program in spite of the Error is a good idea,
> but even that gets suggested sometimes (e.g. trying to catch and recover
> from a RangeError comes up periodically).

Or aside from that strawman that RangeError shouldn't be an Error even...

-Steve

On Tuesday, 10 July 2018 16:48:41 MDT Steven Schveighoffer via Digitalmars-d wrote:
> On 7/10/18 6:26 PM, Jonathan M Davis wrote:
> > On Tuesday, 10 July 2018 13:21:28 MDT Timon Gehr via Digitalmars-d
wrote:
> >> On 03.07.2018 06:54, Walter Bright wrote:
> >>> ...
> >>>
> >>> (I'm referring to the repeated and endless threads here where people argue that yes, they can recover from programming bugs!)
> >>
> >> Which threads are those?
> >
> > Pretty much any thread arguing for having clean-up done when an Error is thrown instead of terminating ASAP. Usually, folks don't try to claim that trying to fully continue the program in spite of the Error is a good idea, but even that gets suggested sometimes (e.g. trying to catch and recover from a RangeError comes up periodically).
>
> 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. In the vast majority of cases, indices do not come from program input, and in the cases where they do, they can be checked by the programmer to ensure that they don't violate the contract of indexing dynamic arrays. And when you consider that the alternative would be for it to be a RangeException, having it be anything other than an error would quickly mean that pretty much no code using arrays could be nothrow.

Regardless, there are sometimes cases where the programmer decides what the contract of an API is (whether that be the creator of the language for something standard like dynamic arrays or for a function in a stray programmer's personal library), and any time that that contract is violated, it's a bug in the program, at which point, the logic is faulty, and continuing to execute the program is risky by definition. Whether a particular contract was the right choice can of course be debated, but as long as it's the contract for that particular API, anyone using it needs to be obey it, or they'll have bugs in their program with potentially fatal consequences.

- Jonathan M Davis

On 7/10/2018 8:39 AM, H. S. Teoh wrote:
> The saving grace to real mode DOS was that rebooting was so fast.

I beg to differ. Boot time has been about the same for the last 40 years :-)

On 7/10/2018 12:21 PM, Timon Gehr wrote:
> On 03.07.2018 06:54, Walter Bright wrote:
>> (I'm referring to the repeated and endless threads here where people argue that yes, they can recover from programming bugs!)
> 
> Which threads are those?

I'd have to google for them. Maybe try searching for "assert terminate program logic bug"

On 7/10/2018 12:21 PM, Timon Gehr wrote:
> Which threads are those?

Here's one:

https://digitalmars.com/d/archives/digitalmars/D/Program_logic_bugs_vs_input_environmental_errors_244143.html

Have fun, it may take upwards of a week to read that one!

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.

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.

On 2018-07-11 03:50, Walter Bright wrote:
> On 7/10/2018 8:39 AM, H. S. Teoh wrote:
>> The saving grace to real mode DOS was that rebooting was so fast.
> 
> I beg to differ. Boot time has been about the same for the last 40 years :-)

The boot time of my computer was reduced from several minutes to around 30 seconds when I switch to SSD disks.

-- 
/Jacob Carlborg

On Wednesday, 11 July 2018 at 16:17:30 UTC, Jacob Carlborg wrote:
>
> The boot time of my computer was reduced from several minutes to around 30 seconds when I switch to SSD disks.

My NVMe ssd is very fast.

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.