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

[Steven Schveighoffer]

On 7/10/18 6:59 PM, Jonathan M Davis wrote:
> 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.

It's all wishful thinking on my part. At this point, no way we can make 
a non opt-in change to RangeException, because so much code will break.

But to be honest, I don't really think RangeException makes much sense 
either. It really is a programming error, but one that is eminently 
recoverable in some cases (it depends completely on the program). It 
stops memory corruption from happening, and as long as you unwind the 
stack out to a place where you can report the issue and continue on, 
then it's not going to affect other parts of the program.

The classic example is a fiber- or thread-based service, where the tasks 
run are independent of each other. It makes no sense to kill all the 
tasks just because one has an off-by-one indexing problem that was 
properly prevented from causing any issues.

> 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.

We are not so much in disagreement on this, I don't think it makes any 
sense to make a RangeError not a programming error. But the problem I 
have with the choice is that an Error *necessarily* makes the entire 
program unusable. In other words, the scope of the problem is expanded 
by the language to include more than it should. And really, it's not so 
much throwing the Error, it's the choice by the language to make nothrow 
functions not properly clean up on an Error throw. Without that 
"feature", this would be a philosophical discussion, and not a real problem.

-Steve