Comparing Exceptions and Errors

[Steven Schveighoffer]

On 6/4/22 7:57 AM, kdevel wrote:
> On Friday, 3 June 2022 at 23:40:50 UTC, Steven Schveighoffer wrote:
>> During the last beerconf, I wrote a short blog post about how `Error` 
>> and `Exception` are different, and why you should never continue after 
>> catching `Error`s.
>>
>> Feedback welcome, I didn't announce here when I wrote it because it's 
>> kind of small/insignificant, but maybe it can help newcomers to the 
>> language: 
>> https://www.schveiguy.com/blog/2022/05/comparing-exceptions-and-errors-in-d/ 
>>
>>
> 
> Here my feedback:
> 
> 1. What if div is called with x = -2147483648 and y = -1? Isn't code
>     which allows a divisor == 0 to propagate to the CPU an error? Must
>     the code thus not throw an object instantiated from a subclass of 
> `Error`?

Well, that is just a toy example to show code that might use an Error. 
It's not intended to be a fully-fleshed-out function. I recommend simply 
using the divide operator in real code.

The point of an `Error` is that your code can assume it cannot happen. 
If it does happen, the code is invalid. This is reflected in the fact 
that the compiler will omit cleanup code if an `Error` is thrown (it can 
assume that it will never happen). The point of using `Error` is for a 
last resort check for program correctness (because you failed to 
validate the input before getting to that point).

> 
>     What if I have that function div used in code which is called from say
>     controller code of a CGI binary. Or likewise from a vibe.d-thread 
> servicing
>     a web request? How do I isolate that fault? Do I have to spawn a 
> subprocess
>     as Walter suggested in the case of memory corruption [1]?
> 
>     [This is of course all rhetorical!]

vibe should exit the process if an `Error` is thrown. There is a version 
you can specify to have it catch `Error`, but it would only be for 
debugging. https://vibed.org/docs#compile-time-configuration (see 
`VibeDebugCatchAll`)

One thing that always bugs me in my vibe code is out of bounds errors 
for arrays. I actually replaced some arrays with an `Exception` throwing 
wrapper because I didn't want to crash the whole server for certain 
cases, and I didn't want to continuously validate array indexes.

> 
> 2. Since 2017 or so I have written some 10 KLOC of D, maybe about two dozen
>     classes deriving from Exception. But I did not annotate any of my 
> methods or
>     function with "nothrow" nor did I author any class deriving from 
> `Error`.
> 
>     What does that mean? Am I `Error` blind?

As long as you aren't catching `Throwable` or `Error`, you should be 
fine. Simply not marking things `nothrow` doesn't mean that they won't 
be inferred `nothrow`. `auto` and template functions are inferred.

In practice, there are probably very very few places where this can bite 
you. Which also means, if it does bite, it's going to be really really 
hard to track down.

> 
> 3. Can you provide some piece of code which *must* throw `Error` and cannot
>     throw an appropriate Exception?

As Paul said, this is up to your API. If you specify that you assume the 
inputs to the function are cleansed, then you can correctly throw an 
Error if they are out of spec.

A great example are range functions. Often times you see at the 
beginning of any `popFront` method the statement `assert(!empty);`. This 
is universally accepted, as you shouldn't be calling `popFront` if you 
haven't checked for `empty`.

-Steve