What is the point of nothrow?

[Jonathan M Davis]

On Monday, June 11, 2018 20:45:52 Dave Jones via Digitalmars-d-learn wrote:
> On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
> > On Sunday, June 10, 2018 23:59:17 Bauss via Digitalmars-d-learn
> >
> > wrote:
> >> What is the point of nothrow if it can only detect when
> >> Exception is thrown and not when Error is thrown?
> >>
> >> It seems like the attribute is useless because you can't
> >> really use it as protection to write bugless, safe code since
> >> the nasty bugs will pass by just fine.
> >>
> >> I'm aware that it's a feature that nothrow can throw Error,
> >> but it makes the attribute completely useless because you
> >> basically have no safety to guard against writing code that
> >> throws Error.
> >>
> >> To an extend @safe works, but there are tons of stuff that
> >> throws Error which you can only detect and guard against
> >> manually.
> >>
> >> So what is the point of nothrow when it can only detect
> >> exceptions you'd catch anyway.
> >>
> >> To me it would be so much more useful if you could detect code
> >> that could possibly throw Error.
> >
> > Why do you care about detecting code that can throw an Error?
> > Errors are supposed to kill the program, not get caught. As
> > such, why does it matter if it can throw an Error?
> >
> > Now, personally, I'm increasingly of the opinion that the fact
> > that we have Errors is kind of dumb given that if it's going to
> > kill the program, and it's not safe to do clean-up at that
> > point, because the program is in an invalid state, then why not
> > just print the message and stack trace right there and then
> > kill the program instead of throwing anything? But
> > unforntunately, that's not what happens, which does put things
> > in the weird state where code can catch an Error even though it
> > shouldn't be doing that.
>
> It certainly threw (hardehar) me when a failed assert was
> terminating my program without telling me why. I don't know if
> it's just because it was happening in an OS callback function,
> but it was definitely a WTF.

Because Errors are handled as Throwables, they have to be caught to print
out what went wrong. So, if you do something like give an extern(C) function
to a C function via a function pointer, and it throws an Error, then you
will probably have to catch it, print it, and then do whatever is
appropriate at that point to shut down the program, whereas if it just
killed the program at the point that the Error was thrown, then that
wouldn't be a problem. So, that's a definite downside to the fact that
Errors are thrown instead of just printing and killing the program. Another
potentially serious downside is that if the program dies at the point of
failure, then you can often get a coredump of the program state to debug it,
whereas if an Error is thrown, then that doesn't happen.

I think that part of what caused this situation is the fact that Walter has
primarily worked on programs where you can restart them to get the same
results (like a compiler). So, he's not used to having to debug a program
failure where the program has been running for who knows how long, and you
don't even know what the program input was. So, he has a tendency to expect
you to be able to rerun the program to get the same results in order to
debug it, whereas folks writing OS or server software are more likely to
expect to have to capture the program state at the point of failure so that
they have some hope of debugging the problem when they have no clue of how
to reproduce it.

> So the only solution I could figure is to catch throwable in the
> callback function, dump the message, and then PostQuitMessage(0).
> It just seems retarded that Throwables can still happen in a
> nothrow function.

Well, it stems from the fact that Exceptions and Throwables are essentially
different things but use essentially the same error-reporting mechanism. In
a way, it make sense (especially in the case where you're dealing with a
single thread that D controls), but I'm inclined to think that it was
ultimately a mistake.

- Jonathan M Davis