On Monday, 3 November 2014 at 03:29:05 UTC, Walter Bright wrote:
I have considerable experience with what programs can do when
continuing to run after a bug. This was on real mode DOS, which
infamously does not seg fault on errors.
It's AWFUL. I've had quite enough of having to reboot the
operating system after every failure, and even then that often
wasn't enough because it might scramble the disk driver code so
it won't even boot.
Yep. Fun stuff.
http://research.microsoft.com/en-us/people/mickens/thenightwatch.pdf
I got into the habit of layering in asserts to stop the program
when it went bad. "Do not pass go, do not collect $200" is the
only strategy that has a hope of working under such systems.
The tough thing is that in D, contracts serve as this early
warning system, but the errors this system catches are also
sometimes benign and sometimes the programmer knows that they're
benign, but if the person writing the test did so with an assert
then the decision of how to respond to the error has been made
for him.
It is my duty to explain how to use the features of the
language correctly, including how and why they work the way
they do. The how, why, and best practices are not part of a
language specification.
I don't entirely agree. The standard library serves as the how
and how and best practices for a language, and while a programmer
can go against this, it's often like swimming upstream. For
better or worse, we need to establish how parameters are
validated and such in Phobos, and this will serve as the template
for nearly all code written in D.
The core design goal of Druntime is to make the default behavior
as safe as possible, but to allow to discerning user to override
this behavior in certain key places. I kind of see the entire D
language like this--it has the power of C/C++ but the ease of use
of a much higher level language. We should strive for all
aspects of the language and standard library to have the same
basic behavior: a safe, efficient default but the ability to
customize in key areas to meet individual needs. The trick is
determining what these key areas are and how much latitude the
user should have.
If D changes assert() to do unwinding, then D will become
unusable for building reliable systems until I add in yet
another form of assert() that does not.
To be fair, assert currently does unwinding. It always has. The
proposal is that it should not.
The reason I initiated this thread is to point out the correct
way to use assert() and to get that into the culture of best
practices for D. This is because if I don't, then in the vacuum
people will tend to fill that vacuum with misunderstandings and
misuse.
It is an extremely important topic.
I still feel like there's something really important here that
we're all grasping at but it hasn't quite come to the fore yet.
Along the lines of the idea that a @safe program may be able to
recover from a logic error. It seems like a uniquely D thing
insofar as systems languages are concerned.
If the operating system can't handle resource recovery for a
process terminating, it is an unusable operating system.
There are all kinds of resources, and not all of them are local
to the system. Everything will eventually recover though, it
just won't happen immediately as is the case with resource
cleanup within a process.
