Personally, I don't appreciate error handling models much which
pollute the return type of each function simply because of the
conclusion that every function you define have to handle errors
as errors can happen everywhere even in pure functions.
You don't believe me? What about memory overflow errors which can
occur in any stack/heap allocation? Don't know how this is
handled in D but in Java you got exceptions for this as well.
The other point is the direction which is chosen in Go and Rust
to make error handling as deterministic as possible by
enumerating all possible error types.
Afaict, this isn't a good idea as this increases the fragile code
problem by over specifying behavior. Any change requires a
cascade of updates if this is possible at all.
What you do in Rust then?, simply panic?
Though, it doesn't mean that it is bad in every case.
By churning different language design forums it all comes down to
the point, every time, that the default error handling model
equipped with the considered language is dump and that people
call for extensions from other languages, even ones which include
exception handling to improve things.
I see this in Rust and Go and even in Swift forums that people
are annoyed how it currently works.
No error handling model was the HIT and will never be, therefore
I would recommend to leave things as they are and to develop
alternatives and not to replace existing ones.
