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

[H. S. Teoh]

On Wed, Dec 16, 2020 at 08:49:41PM +0100, Jacob Carlborg via Digitalmars-d wrote:
> 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.

Exceptions don't have to be classes, even though that's the most obvious
way to implement it.  For example, it could be a runtime-defined struct
that contains the most pertinent information, with an optional
polymorphic reference to additional information that people might want
to transmit along with their exceptions.


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

It's not that the type itself is opaque, it's that since you can throw
*any* arbitrary type, the catching code cannot predict in advance what
the concrete type(s) the caught exception will be, and therefore it
cannot make any assumptions about the type of the exception, including
what operations are permitted on it.  It cannot assume there's a .msg
field that contains an error message, for instance, since somebody could
have thrown an int. Or any type without a .msg member, for that matter.


> > Maximum flexibility isn't always a good thing.
> 
> I've been thinking about limiting the types to user defined types.
[...]

Even so, if there is no standard API that exceptions must implement,
then you cannot write top-level catch that does something useful (beyond
just printing "Error" and aborting).  There must be some kind of minimum
set of attributes that you can depend on, like a string .msg. Possibly
also .file and .line.


T

-- 
Gone Chopin. Bach in a minuet.