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
