On Wednesday, 3 April 2013 at 15:29:01 UTC, deadalnix wrote:
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).

Well the word "range" has two meanings here: One is the programming language concept, i.e. a type that defines empty, front, etc. The other is the English word for which Google offers the following definition: "The area of variation between upper and lower limits on a particular scale." In light of this, I don't think RangeError is a bad name for an array bounds violation.


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.

Of course it's not impossible.

std.range.iota
std.range.recurrence
std.range.sequence

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.

This is not always possible or convenient. Assume the directory "foo" contains 4 files.

    auto fourFiles = std.file.dirEntries("foo", SpanMode.shallow);
    auto twoFiles = std.range.take(fourFiles, 2);
    twoFiles.popFront();
    twoFiles.popFront();
    twoFiles.popFront();

Which exception should the last popFront() throw?

Lars

Reply via email to