Program logic bugs vs input/environmental errors

[Sean Kelly via Digitalmars-d]

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.