Discussion Thread: DIP 1038-- at nodiscard--Community Review Round 1

[H. S. Teoh]

On Fri, Dec 11, 2020 at 08:54:58PM +0100, Jacob Carlborg via Digitalmars-d wrote:
> On 2020-12-11 09:03, Guillaume Piolat wrote:
[...]
> > I'd be more excited about:
> > - throw-by-value exceptions
> > - a way to use exceptions in @nogc and even -betterC (There was a DIP
> > for it, it was implemented, but doesn't work IIRC)
> > than improving error codes.
> 
> I completely agree. Instead of this approach, the compiler could lower
> try/catch/finally/throw for a function to return tagged union of the
> success value and all the exceptions that can be thrown.

Yes!  Lightweight by-value exceptions will be a plus in my book.


> Then one could easily throw any kind of types, not just classes
> inheriting from `Throwable`, including value types.
[...]

But I don't agree with this.

I used to write a lot of C++, where you can throw literally *anything*.
It seems to be a good thing to allow maximum flexibility, but that
actually hinders code interoperability: you cannot assume *anything*
about something you caught, because it can literally be *any* type.  D's
Throwable API is much better because it guarantees a minimal common
interface that all catch blocks can depend on.  Having a standard .msg
field that returns a string you can print to the user in the event you
need to abort, e.g., is much more useful than an opaque type that you
can't do anything with other than say "an error occurred, abort" -- what
error? Don't know, can't know, the catch block in main() has no idea
where it came from or what information might be encoded within.
Knowledge about the error might only exist inside a 3rd party
dependency.

Maximum flexibility isn't always a good thing.


T

-- 
Study gravitation, it's a field with a lot of potential.