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
