nothrow by default
Adam D. Ruppe
destructionator at gmail.com
Sat Jan 4 23:06:48 UTC 2020
On Saturday, 4 January 2020 at 21:38:53 UTC, Walter Bright wrote:
> The short rationale is that exceptions being a "pay only if you
> use them" is a complete fraud. They're expensive to support,
> meaning performance programs use other ways of signalling
> errors and use nothrow.
There's more to code than performance. D is an all-purpose
language.
But anyway, D still allows throwing from nothrow, but only if it
is the Error class. I presume that would not change.
Would you make throw Error instead just maybe try to print the
message to stderr then abort? That's not a bad idea, and is
compatible with D's spec as it stands now. (the print to stderr
could be problematic in some contexts but we'd just do a runtime
function override in that case)
Then you wouldn't need any EH framing around it. This could be
done without changing the default too.
But my worry on nothrow by default in general is then more D code
will just become fragile since other error methods have
historically meant they simply get ignored and not even
reported.... barring something like those newfangled type based
systems that's probably what we'd become too.
BTW I have some other potential uses for those newfangled type
based systems. I wouldn't object to getting some of those pieces
in too - we can already do much of it.
If 1) there was a way to say "ignoring the return value of this
function is an error" (but that cannot apply everywhere!) and 2)
be able to return from the caller from a callee (think of C
macros that like `if(!SUCCEEDED(hr)) return hr` type of thing), I
think we could do some real magic and have a serious alternative
to exceptions. And do other useful things too.
My suggestion would be to do those before attempting nothrow by
default too. (then we can still vote down the default change and
be left with new tools for people who want to use them :P )
More information about the Digitalmars-d
mailing list