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.
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.
