DIP33: A standard exception hierarchy

[deadalnix]

On Thursday, 4 April 2013 at 21:25:18 UTC, Jonathan M Davis wrote:
> 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

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.