Comparing Exceptions and Errors

[kdevel]

On Sunday, 5 June 2022 at 01:43:06 UTC, Steven Schveighoffer 
wrote:

[...]

> But you aren't perfect, and so maybe you make a mistake, and 
> trigger an Error. The compiler handles this unexpected 
> condition by unwinding the stack back to the main function, 
> printing the error and exiting, so you can go fix whatever 
> mistake you made.

For this purpose nobody needs a separate subclass named `Error`. 
That works with `Exception`s.

[...]

>> 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.

> 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]

[...]
> 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.

> Having the assert allows diagnosing invalid programs without 
> crashing your program,

That depends on the understanding of "crashing a program". If 
library code throws an `Error` instead of an `Exception` I have 
to isolate that code in a subprocess in order to make my program 
gracefully handle the error condition.

Think of CGI processes which provide output direct to a customer. 
If there is an assert the customer will see the famous Internal 
Server Error message (in case of apache httpd).

[...]

[1] http://wiki.c2.com/?AssertionsAsDefensiveProgramming