DIP33: A standard exception hierarchy

[deadalnix]

On Wednesday, 3 April 2013 at 09:40:27 UTC, Lars T. Kyllingstad 
wrote:
> For arrays, RangeError is synonymous with "out of bounds".  I 
> see no reason to invent a new class just for this purpose.
>

Exactly, no need for RangeError (as out of bound access can be 
produced in many situation that don't involve ranges).

> And note that I'm not saying that ranges should be restricted 
> to *only* throwing RangeErrors.  Generally, it should be used 
> in situations that are analogous to out of bounds for arrays, 
> such as trying to pop past the end of the range.
>

The data always come from somewhere. That somewhere can't provide 
anymore data for a reason. Because you reached the end of a file 
(IOException or something) because the network disconnected 
(NetworkException) or whatever.

RangeError imply that the data magically appears from a range, 
without any actual source, which is impossible.

> However, some ranges may want to do something else in this 
> situation.  An output range that writes to a file, for 
> instance, may want to throw a "disk full" exception.  A wrapper 
> range may simply propagate any errors from the underlying range.
>

Exactly. In general, wrapper should simply forward calls and let 
the source fail when its own logic isn't involved.

> RangeError is for the cases when it is not possible/necessary 
> to provide more detail than "you tried to call popFront on an 
> empty range, which is illegal".
>

It is always illegal for a reason.