Alternatives to exceptions for error handling

IGotD- nise at
Mon Nov 23 00:12:28 UTC 2020

On Sunday, 22 November 2020 at 18:21:44 UTC, Paul Backus wrote:
> The biggest blocker for this is that D currently has no 
> equivalent of Rust's `#[must_use]` and C++'s `[[nodiscard]]`. I 
> have a DIP in the works to address this:
>> 2. Some kind of syntactic sugar for propagating errors 
>> upstream (? macro in Rust, check/handle proposal in Go 
>>, an ugly macro in C++, etc.).
> So far the only proposal I've heard on this front is the idea 
> of bringing Herb Sutter's deterministic exceptions [1] to D. 
> But there are no concrete plans at this point, not even a DIP.
> My expectation is that, like in Rust, the first thing to arrive 
> will be monadic `map`/`flatMap` methods, since those can be 
> implemented using only library code.
> [1] 

Doesn't the lean exceptions what Herb Sutter proposes have the 
same problem as normal exception, that the data flow analysis 
gives up. Anything that requires unwinding is not going to fit 
for that purpose.

Rust error handling does not rely on exceptions or unwinding but 
rather just a return type which is a tagged union. Essentially 
Rust error handling is like good old return values. The only 
difference is that compiler inserts code when the result type 
isn't handled or passed to the caller. I don't understand why 
nobody thought about that previously because it is kind of simple.

Any method that removes the dependency to libunwind gets my vote.

More information about the Digitalmars-d mailing list