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.
