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
