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

[Jacob Carlborg]

On 2020-12-11 21:27, H. S. Teoh wrote:

> 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

Yeah, I've been thinking about how to best solve that. My vision extends 
a bit more than just a different implementation of exception handling. 
I want the error handling to be usable everywhere, including low level 
code. Ideally it should be usable without a runtime. As soon as you 
start requiring classes, that will impose limitations.

> 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.

In my vision it wouldn't be an opaque type. But it would be good to have 
a way to handle all errors in one place.

> Maximum flexibility isn't always a good thing.

I've been thinking about limiting the types to user defined types.

I should really try to write down my ideas regarding this.

-- 
/Jacob Carlborg