On Monday, 11 June 2018 at 04:11:38 UTC, Bauss 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.
As for the benefits of nothrow, as I understand it, they're
twofold:
1. You know that you don't have to worry about any Exceptions
being thrown from that code. You don't have to worry about
doing any exception handling or having to ensure that anything
gets cleaned up because of an Exception being thrown.
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 that it normally does when a function
is called. It can assume that nothing ever gets thrown. If an
Error does get thrown, then none of the proper clean-up will
get done (e.g. constructors or scope statements), but because
an Error being thrown means that the program is in an invalid
state, it's not actually safe to be doing clean-up anyway. So,
the fact that a function is nothrow gives you a performance
benefit, because none of that extra Exception handling stuff
gets inserted. How large a benefit that is in practice, I
don't know, but it is a gain that can't be had with a function
that isn't nothrow.
- Jonathan M Davis
Well at least from my point of view I would care about code
that can throw Error, because if say nothrow could detect that
then you could prevent writing that code that throws jt at all
and thus you'd be writing less error prone code.
Maybe not necessarily nothrow, but something else that could
ensure that your code is "100% safe" to run without any errors
happening from ex. Accessing out of bounds, accessing invalid
memory, attempting to access the member of an uninitialized
class etc. Like you'd have to handle each such cases. Writing
code in D today you have to think about each statement you
write and whether it could possibly throw Error because you
have little to no tools that helps you preventing writing such
code.
I'm very well aware that Error is not supposed to be caught and
that the program is in an invalid state, but ehat I'm trying to
get at is that if nothrow or at least a feature similar existed
that could detect code that may throw Error, then you could
prevent writing code that throws it in the first place.
It would be a great tool to writing bugless code.
There's nothing unsafe about Error getting thrown in your code.
Error makes your program more safe, because it terminates the
program immediately instead of letting it do stuff like corrupt
memory or crash the system.
Error getting thrown denotes a logic error in your program. Some
base assumption you've made is not actually true, and thus the
program is in an invalid state and must exit immediately. The
reason why nothrow cannot help you here is because these are
logic errors that are only detectable at runtime. If it was
possible to detect these types of errors at compile time, then
there would be no need for Error.