On Sunday, 5 October 2014 at 23:01:48 UTC, Walter Bright wrote:
On 10/5/2014 2:51 PM, Dicebot wrote:
On Sunday, 5 October 2014 at 20:41:44 UTC, Walter Bright wrote:
On 10/5/2014 8:35 AM, Dicebot wrote:
I am fine with non-default being hard but I
want it to be still possible within legal language
restricions.
D being a systems language, you can without much difficulty
do whatever works
for you.
Yes but it shouldn't be in undefined behaviour domain. In
other words there
needs to be a confidence that some new compiler optimization
will not break the
application completely.
Relying on program state after entering an unknown state is
undefined by definition. I don't see how a language can make a
statement like "it's probably ok".
It is only in undefined state because language handles Errors
that way. At the point of throwing the Error state was perfectly
defined and 100% recoverable. This is the typical case for
assertion failure in contract - it detects some program flaw like
inability to handle specific data combination from other process
but it does not mean memory is corrupted or program is inherently
broken. Just killing the fiber and continuing with other requests
(which don't trigger that unexpected code path) is absolutely
fine unless compiler kicks in and optimizes something away in
surprising fashion.
If destructors are ignored those must be always ignored and
defined in spec. Same for scope(exit) or any similar affected
feature. Currently it may or may not attempt cleanup and that is
the problem when trying to circumvent the semantics.
I think this is the only important concern I have as long as
power user stuff
remains possible without re-implementing whole exception
system from scratch.
You can catch an Error. But what is done from there is up to
you - and to do more than just log the error, engage the
backup, and exit, I cannot recommend.
Killing whole process is unacceptable in many cases, it will
effectively shut down the whole service if faulty request happens
at least one in a few seconds.
To do more, use an Exception. But to throw an Exception when a
logic bug has been detected, then try and continue based on it
"probably" being ok, is something I cannot recommend and D
certainly cannot guarantee anything. If the program does
anything that matters, that is.
Assertions / contracts use Error. Do you think it is a better
approach to prohibit using `assert` and throw custom exceptions
from contracts?
