On Sunday, 5 June 2022 at 20:53:32 UTC, Steven Schveighoffer
wrote:
[...]
For this purpose nobody needs a separate subclass named
`Error`. That works with `Exception`s.
You can use Exceptions instead. But the difference is they are
part of the program instead of considered a check on the
program itself.
I have no clue what that means.
[...]
If the code threw an `Exception` instead of an `Error`
everything would be fine.
I think the point of Errors is that you can remove them for
efficiency.
elephant/room.
Why? If you have a correct program, you shouldn't ever have
errors thrown. If you do have errors thrown that's something
you need to address ASAP.
My code does not throw `Error`s. It always throws `Exception`s.
In other words, just like asserts or bounds checks, they are
not expected to be part of the normal working program.
"removing [Errors, asserts, bounds checks] is a bit like
wearing a life-jacket to practice in the harbour, but then
leaving the life-jackets behind when your ship leaves for open
ocean" [1]
It's more like leaving the floaties behind when you are doing a
swim meet.
Nice new question for job interviews.
[...]
Consider the normal flow of a range in a foreach loop, it's:
```d
// foreach(elem; range)
for(auto r = range; !r.empty; r.popFront) {
auto elem = r.front;
}
```
If both `popFront` and `front` also always call `empty` you
are calling `empty` 3 times per loop, with an identical value
for the 2nd and 3rd calls.
Solution: Implement explicitly unchecked popFront() and
front() versions.
That's terrible. Now I have to instrument my code whenever I
have a weird unknown error,
Well, no. Just use the default. It will throw an exception if
something goes wrong. Of course, I must admid, if you want to
compete with those I-have-the-fastest-serving-http-server-guys
(N.B.: HTTP not HTTPS! Did anybody notice that?) reporting 50
Gigarequests per second (or so) then you probably have to
*measure* *the* *performance* of the range/container
implementation. But not earlier.
changing all range functions to use the `checkedPopFront` and
`checkedFront`, just to find the error. Instead of letting the
asserts do their job.
It is not clear to me, what you now complain about. You first
criticized that in
```
for(auto r = range; !r.empty; r.popFront) {
auto elem = r.front;
}
```
there is triple checking that r is not empty, namely in !r.empty,
in r.front and in r.popFront. One check, !r.emtpy, will suffice.
Hence one can safely use
```
for(auto r = range; !r.empty; r.popFront_unchecked) {
auto elem = r.front_unchecked;
}
```
If you don't trust whomever you can simply keep the checked
versions. The test will then be performed thrice regardless if a
test failure will result in throwing an `Exception` or throwing
an `Error`. AFAICS.
[...]
