nothrow by default

Mathias Lang pro.mathias.lang at gmail.com
Fri Jan 10 08:19:10 UTC 2020


On Friday, 10 January 2020 at 01:28:35 UTC, Walter Bright wrote:
> On 1/9/2020 2:10 PM, Timon Gehr wrote:
>> On 09.01.20 11:32, Jonathan M Davis wrote:
>>> I wouldn't mind us getting rid of Error in favor of killing 
>>> the program on
>>> the spot, since that's actually better for debugging,
>> 
>> It really depends. There are situations where it may be 
>> better, but if you are trying to debug a non-deterministic 
>> condition that happens very rarely on someone else's machine 
>> exclusively in release builds, depending on a lot of user 
>> input, druntime shutting down the code that is supposed to 
>> collect enough information for you to have a chance to figure 
>> out what is going on in detail can hardly be described as 
>> "better". It should be possible to hook the kill function at 
>> least.
>
> Hooking the kill function is the way to do that - much better 
> than exception unwinding.

Sounds like a good idea, looking forward to that DIP.

I would consider `nothrow` by default, like others, as seriously 
crippling to the language.
However improving the efficiency, or changing the scheme, sounds 
like it would achieve everyone's goal.

To give an example of a real world issue we have:
- A server handling connections
- We call `formattedWrite` with a `nothrow` sink and `nothrow` 
arguments (`toString` & co)
- `formattedWrite` is not `nothrow`

Why ? Because `std.format` is *full* of `enforce` calls to check 
the format string.
So what should we do with them ? We *could* consider it user 
error (because the programmer didn't provide the proper format 
string) and just bulk-replace it with `Error`.

But now, something as trivial as a wrong format string will crash 
my server, and for an error which is most likely recoverable 
(which is I guess the original reasoning behind the `enforce` 
calls).
And such error are common, and can be in paths that are almost 
never triggered (e.g. an error message when the filesystem is 
full).

So all things considered, having a non-`nothrow` `std.format` 
seems like the best compromise until someone comes up with a 
smart way to solve this without another downside. The same 
reasoning apply to many, many places, and that's why `nothrow` by 
default wouldn't make sense to me.

Note at the moment, you can turn a non-`nothrow` function into a 
`nothrow` function with a single line of code:
```
void myFunc() nothrow
{
     scope (failure) assert(0); // This makes the function 
`nothrow`
     formattedWrite(...);
}
```
So in D, you can have non-`nothrow` function and a backtrace via 
exceptions, or `nothrow` function and a backtrace (abort in 
release mode). I think that we have it pretty good.

P.S: https://issues.dlang.org/show_bug.cgi?id=20487


More information about the Digitalmars-d mailing list