What is the point of nothrow?

[wjoe]

On Thursday, 14 June 2018 at 19:06:07 UTC, Jonathan M Davis wrote:
> On Thursday, June 14, 2018 18:11:20 wjoe via 
> Digitalmars-d-learn wrote:
>> On Wednesday, 13 June 2018 at 20:08:06 UTC, Jonathan M Davis 
>> wrote:
>> > On Wednesday, June 13, 2018 10:56:41 wjoe via
>> > The idea is that because your program is in an invalid state,
>> > attempting a graceful shutdown is unsafe. But regardless of
>> > whether you agree with that, the fact that nothrow doesn't do
>> > clean-up pretty much ensures that it isn't safe in the 
>> > general
>> > case, and nothrow can't do clean-up without negating one of 
>> > the
>> > main reasons that it exists in the first place - which is to
>>
>> that fact also means that a program which threw an Error 
>> cannot be debugged anymore; because of invalid state you can 
>> neither know, nor assume, that what you see in your debugger 
>> or core dump is actually the state which led to the throw.
>
> As I said, personally, I think that the program shut just print 
> and terminate rather than throwing an Error. Walter seems to 
> have designed things from the premise that you could rerun the 
> program to reproduce the problem (which in is usually true with 
> the programs he works on). And in that case, simply getting the 
> error message and stacktrace would be plenty. The problem is 
> when you can't simply rerun the program to reproduce the 
> problem and is why I'm of the opinion that printing and 
> terminating would be better than throwing an Error.
>
>> > improve performance by not emitting exception-handling code.
>>
>> if performance matters so much I would use betterC.
>>
>> 'Improving' performance without profiling and such a trade-off 
>> is a bad idea. If it were opt in - yes, I know I will get 
>> undebuggable code on error thrown but I want or need the 
>> performance gain, fair enough. But instead you are a victim of 
>> that implementation whether you like it or not and you might 
>> not even be aware about it.
>
> betterC really has nothing to do with performance. It just has 
> to do with avoiding druntime so that you can have C code just 
> link in and use the D code as if it were C (though using it 
> would avoid the issue of Errors, since the runtime wouldn't be 
> there to handle them). And again, Errors are intended for fatal 
> cases, so most of the concerns about doing clean-up are 
> irrelevant. Attempting to recover from an Error is considered 
> to be like attempting to recover from a segfault, which is a 
> terrible, terrible idea. And there are plenty of folks who want 
> to be able to have their code be more performant when it's not 
> using exceptions. So, as long as folks aren't trying to catch 
> Errors, the fact that nothrow doesn't emit the exception 
> handling code really isn't a problem.
>

What you said earlier:
On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
>
> [...]
>
> 2. If the compiler knows that a function can't throw an 
> Exception, then it doesn't have to insert any of the Exception 
> handling mechanism stuff [...] So, the fact that a function is 
> nothrow gives you a performance benefit, [...]
>
> - Jonathan M Davis

made me believe that performance is one of the major reasons to 
use it. No?

 From the betterC page https://dlang.org/spec/betterc.html section 
40.2:
---
Not Available

D features not available with BetterC:

     Garbage Collection
     TypeInfo and ModuleInfo
     Classes
     Built-in threading (e.g. core.thread)
     Dynamic arrays (though slices of static arrays work) and 
associative arrays
     Exceptions
     switch with strings
     final switch
     synchronized and core.sync
     Static module constructors or destructors
     Struct destructors
     unittest (testing can be done without the -betterC flag)
---
Apart from a few convenience features lost this list reads like a 
shopping list for performance gain over full fledged D, in the 
spirit of nothrow omitting exception handling mechanism, to me. 
You gain from no garbage collection overhead, no vtable overhead, 
no RTTI overhead, no exception overhead, etc, etc, ...

Back in the late 90ies I used to write the lion's share of code 
in Pascal and implement mission critical algorithms in asm. 
Worked back then why wouldn't it work today, except that I 
wouldn't use asm anymore but something like C or betterC.

Thus, people who need this kind of performance boost can benefit 
2 fold from using betterC.
1. They get to keep most of D's awesomeness, including compile 
time features, scope statements, RAII, lack of a pre processor, 
memory safety protections and complete meta programming, are just 
_some_ of the highlights. And on the other hand
2. they gain by getting rid of a lot the 'performance hogs' like 
GC, exceptions and more, right?
And, with no exceptions altogether they do not need to worry 
about it at all.

I'm sold!


>> And out of curiosity again, where would I find this place 
>> where the printing and terminating occurs ?
>
> I'd have to go digging in druntime. I don't know. I've probably 
> seen it before, but it's not code that I've dealt with often 
> enough to remember exactly where it is off the top of my head.

druntime. that's a starting point. Thanks.


>> Aborting with an error code would be sufficient. No need to 
>> print
>> anything.
>> A backtrace can be obtained in the debugger.
>
> Given that a coredump isn't always generated (and in the case 
> of Windows, I don't know if they even have an equivalent), 
> printing out the same information that gets printed out now 
> would often be desirable. It's just that if it kills the 
> program right there rather than doing any unwinding of the 
> stack, then the coredump is for the state of the program at the 
> point of failure like it arguably should be.

true enough, but I'm sure that the average user wouldn't know 
what to do with a stack trace in a console and would have closed 
it long before contacting tech support.
We're speaking of rare errors so chances are high that they 
happen in shipped code.
Also, as I noted above in a previous post, there might not even 
be a console(like device) attached to be able to print the error 
and stack trace.

I also believe that Exceptions and Errors should not carry a 
message string because 1. the Exception/Error name carries the 
reason in itself, 2. you can't work well with strings and 3. l18n.

It would be better to write that data out into a file and inform 
the user there was a problem and they should please submit file a 
and file b to the developer, if possible with a description of 
what they were doing. That is for Exceptions.
In case of an Error just inform them that the program crashed and 
cannot be recovered and they should just restart it and apologies 
for the inconvenience.
They needn't bother about sending anything because that info is 
just a dump of invalid program state.

Windows creates core dumps, except they use their own 
terminology. I believe to recall they come in 2 flavors, full- 
and mini-dumps but to my knowledge, which is older than 12 years, 
those were uploaded to MS and you needed to have a Visual Studio 
enterprise level subscription or be a registered developer to be 
able to retrieve them from MS, that is the ones that were created 
on machines you don't have access to. I don't know what the 
current way to do it is.

I think it's possible to generate a core dump via gencore, and 
Windows has MiniDumpWrite or something to that end.