nothrow by default

Adam D. Ruppe destructionator at
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 

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