DIP33: A standard exception hierarchy

[Jonathan M Davis]

On Thursday, April 04, 2013 14:13:55 Ali Çehreli wrote:
> On 04/04/2013 12:16 PM, Ali Çehreli wrote:
> > core.exception.RangeError at 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