On Thursday, April 04, 2013 14:13:55 Ali Çehreli wrote: > On 04/04/2013 12:16 PM, Ali Çehreli wrote: > > core.exception.RangeError@deneme(125887): Range violation > > I have realized something: Maybe some of the confusion here is due to > range violation being an Error. > > I think that it should be an Exception. The rationale is, some function > is told to provide the element at index 100 and there is no such > element. The function cannot accomplish that task so it throws an > Exception. (Same story for popFront() of an empty range.) > > My earlier comments about invalid program state apply to Error > conditions. (Come to think of it, perhaps even more specifically to > AssertError.)
Those are Errors for arrays. Sure, someone could choose to write their containers or ranges in a way that throws an exception when you try and access an element that isn't there, but that then incurs a performance cost for the program as a whole, which would be particularly bad if the standard library then made that decision. In most cases, you know whether the element is there or not, and if you don't it's easy to check, so from an efficiency standpoint, it makes far more sense to treat out of bounds errors (which is what RangeError really is) as Errors. Phobos definitely take the approach that accessing an element in a range that isn't there is an Error (be it by calling popFront on an empty range or using opIndex to an element which isn't there or whatever), and in general, I think that that's very much the correct approach. 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. - Jonathan M Davis
