Alternatives to exceptions for error handling
nise at nise.com
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
>> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md, 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  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.
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