Program logic bugs vs input/environmental errors

[Walter Bright via Digitalmars-d]

On 9/28/2014 6:17 PM, Sean Kelly wrote:
> On Sunday, 28 September 2014 at 22:00:24 UTC, Walter Bright wrote:
>>
>> I can't get behind the notion of "reasonably certain". I certainly would not
>> use such techniques in any code that needs to be robust, and we should not be
>> using such cowboy techniques in Phobos nor officially advocate their use.
>
> I think it's a fair stance not to advocate this approach.  But as it is I spend
> a good portion of my time diagnosing bugs in production systems based entirely
> on archived log data, and analyzing the potential impact on the system to
> determine the importance of a hot fix.  The industry seems to be moving towards
> lowering the barrier between engineering and production code (look at what
> Netflix has done for example), and some of this comes from an isolation model
> akin to the Erlang approach, but the typical case is still that hot fixing code
> is incredibly expensive and so you don't want to do it if it isn't necessary.
> For me, the correct approach may simply be to eschew assert() in favor of
> enforce() in some cases.  But the direction I want to be headed is the one
> you're encouraging.  I simply don't know if it's practical from a performance
> perspective.  This is still developing territory.

You've clearly got a tough job to do, and I understand you're doing the best you 
can with it. I know I'm hardcore and uncompromising on this issue, but that's 
where I came from (the aviation industry).

I know what works (airplanes are incredibly safe) and what doesn't work 
(Toyota's approach was in the news not too long ago). Deepwater Horizon and 
Fukushima are also prime examples of not dealing properly with modest failures 
that cascaded into disaster.