On Thursday, April 04, 2013 23:50:25 deadalnix wrote: > On Thursday, 4 April 2013 at 21:25:18 UTC, Jonathan M Davis wrote: > > There are obviously exceptions to that (e.g. the in operator), > > but as far as > > indexing, slicing, and popFront go, it should be considered a > > programming bug > > if they're used on elements that aren't there. > > It is where the current design choice make no sense. > > If they are error, the recovery code isn't executed. Such > operation don't put the program in an invalid state (in fact, it > prevent the program to go in invalid state). In such situation, > not running that recovery code is likely to transform a small > error into a huge mess. > > The case is very different from Ali's example before, where the > wrong file can be deleted.
Well, the program has no way of knowing _why_ popFront is being called on an empty range or an invalid index is being passed to opIndex or opSlice. The fact that it happened is proof that either there's a programming bug or that things are corrupted and who-knows-what is happening. In either case, the program has no way of knowing whether it's safe to run the clean-up code or not. It could be perfectly safe, or things could already be in seriously bad shape, and running the clean-up code would make things worse (possibly resulting in things like deleting the wrong file, depending on what the clean- up code does and what went wrong). The problem is that while it's frequently safe to just run the clean-up code, sometimes it's very much _not_ safe to run it (especially if you get memory corruption in @system code or something like). And we have to decide which risk is worse. And one good thing to remember is that Errors should be _extremely_ rare. They should basically only happen in debug builds when you're writing and debugging the program and in released code when things go horribly, horribly wrong. And that would mean that it's far more likely that in production code, Errors are normally being thrown in situations where doing clean-up is likely to make things worse. Another good thing to remember is that there's _never_ any guarantee that clean-up code wil actually run, because your program could be forcibly killed in a way that you can't control or protect against (e.g. the plug being pulled), so if your code truly relies on the clean-up code running for it to work properly when it's restarted or leave your system in a consistent state or anything like that, then you're pretty much screwed regardless of whether clean-up is done on Errors. - Jonathan M Davis