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