Permalink
Reply
On 6/5/22 8:45 AM, kdevel wrote:
>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 Exceptions.
You can use Exceptions instead. But the difference is they are part of the program instead of considered a check on the program itself.
There's a need for both.
>[...]
> >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.
> >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.
>[...]
>Consider the normal flow of a range in a foreach loop, it's:
// 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, changing all range functions to use the checkedPopFront and checkedFront, just to find the error. Instead of letting the asserts do their job.
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.
You don't gracefully handle the error condition. It's like saying gracefully handling running into the guardrail on a road. You just crash, and hope you don't die. You don't just graze into it and keep going thinking "well, the guardrail did it's job, glad it's there, I plan on using it every time I go around that corner."
>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).
An assert triggering means, your code did something invalid. It should crash/exit.
Now we can have totally separate debates on what should be an Error and what should be an Exception. And not to belittle your point, I understand that there can be a philosophy that you only want recoverable throwables for certain code domains (I myself also have that feeling for e.g. out of bounds errors). It's just not what D picked as an error handling scheme. We have both recoverable exceptions, and non recoverable errors.
-Steve
