[swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

[Dave Abrahams]

on Tue Jan 17 2017, Jonathan Hull <jhull-AT-gbis.com> wrote:

>> On Jan 17, 2017, at 7:13 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>> 
>> 
>> on Tue Jan 17 2017, Jonathan Hull <jhull-AT-gbis.com <http://jhull-at-gbis.com/>> wrote:
>> 
>
>>> Bringing it back towards the initial post, what if there was a
>>> separation from true needs-to-take-down-the-entire-system trapping and
>>> things like out-of-bounds and overflow errors which could stop at
>>> thread/actor bounds (or in some cases even be recovered)?
>>> 
>>> The latter were the ones I was targeting with my proposal.  They live
>>> in this grey area, because honestly, they should be throwing errors if
>>> not for the performance overhead and usability issues.  
>> 
>> I fundamentally disagree with that statement.  There is value in
>> declaring certain program behaviors illegal, and in general for things
>> like out-of-bounds access and overflow no sensible recovery (where
>> “recovery” means something that would allow the program to continue
>> reliably) is possible.  
>
> I think we do fundamentally disagree.  I know I come from a very
> different background (Human-Computer Interaction & Human Factors) than
> most people here, and I am kind of the odd man out, but I have never
> understood this viewpoint for anything but the most severe cases where
> the system itself is in danger of being compromised (certainly not for
> an index out of bounds).  In my mind “fail fast” is great for
> iterating in development builds, but once you are deploying, the
> user’s needs should come ahead of the programmer’s.

The question is really whether continuing when the program no longer
understands its own state is in the user's best interest.  Bad
consequences are just as easy to imagine as benign ones.

>
>
> Shouldn’t a system be as robust as possible and try to minimize the
> fallout from any failure point?  I don’t consider crashing and losing
> all of the user’s data minimal.  

That's why we need emergency shutdown facilities.


-- 
-Dave