Comparing Exceptions and Errors

[kdevel]

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.

[...]