Bad array indexing is considered deadly

[H. S. Teoh via Digitalmars-d]

On Wed, May 31, 2017 at 02:30:05PM -0700, Ali Çehreli via Digitalmars-d wrote:
> On 05/31/2017 02:00 PM, Steven Schveighoffer wrote:
[...]
> > The runtime should not assume that crashing the whole program is
> > necessary when an integer is out of range. Preventing actual
> > corruption, yes that is good. But an Exception would have done the
> > job just fine.
> 
> How could an Exception work in this case? Catch it and repeat the same
> bug over and over again? What would the program be achieving? (I
> assume the exception handler will not arbitrarily decrease index
> values.)
[...]

In this particular case, the idea is that the fibre that ran into the
bug would throw an Exception to the main loop, which catches it and
terminates the fibre (presumably also sending an error response to the
client browser), while continuing to process other, possibly-ongoing
requests normally.

Rather than having the one bad request triggering the buggy code and
causing *all* currently in-progress requests to terminate because the
entire program has aborted.

An extreme example of this is if you had a vibe.d server hosting
multiple virtual domains belonging to different customers. It's bad
enough that one customer's service would crash when it encounters a bug,
but it's far worse to have *all* customers' services crash just because
*one* of them encountered a bug.

This is an interesting use case, because conceptually speaking, each
vibe.d fibre actually represents an independent computation, so any
fatal errors like out-of-bounds bugs should cause the termination of the
*fibre*, rather than *everything* that just happens to be running in the
same process.  If vibe.d had been implemented with, say, forked
processes instead, this wouldn't have been an issue.  But of course, the
fibre implementation was chosen for performance (and possibly other)
reasons. Forking would give you the per-request isolation needed to
handle this kind of problem cleanly, but it also comes with a hefty
performance price tag.  Like all things in practical engineering, it's a
tradeoff.

I'd say creating a custom type that throws Exception instead of Error is
probably the best solution here, given what we have.


T

-- 
The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis