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

[Jonathan Hull]

As one example of an algorithm which would be helped, I recently had a project which had to do arithmetic on random values.  Figuring out if an operation is going to overflow/underflow without overflowing/underflowing requires a bunch of lines of code which obscure the main logic.  It would be much easier to just do the operation, then catch the error if it happens and apply the special case for that. The code would be much more readable.

The same arguments could be made of user entered values, which are hard to reason about before hand.  Being able to move forward as if they are not going to cause a problem and then catching any problems which do happen (so that the appropriate error can be shown… perhaps modelessly) is much clearer and also much more friendly than crashing their program (potentially taking any unsaved data with it).

Thanks,
Jon


> On Jan 17, 2017, at 2:45 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> 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.  My solution was to give the compiler a way to know that this was the desired behavior and optimize the throwing away unless it was explicitly requested.
> 
> I guess another option would be to introduce a new concept for this grey type of error.  Maybe instead of ‘fatalError’ you have something with a different name saying “this should only take down the current actor”… and then you add a well defined process for cleanup.
> 
> I would still really like to see the ability to turn this type of thing into normal throwing error handling, so maybe something like ‘fatalThrow’ which takes the same information as ‘throw’, so that it can be converted to a standard throw by the caller, but otherwise traps and takes down the actor.  That would make certain types of algorithms much simpler for me.
> 
> Thanks,
> Jon
> 
>> On Jan 17, 2017, at 11:49 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> on Mon Jan 16 2017, Chris Lattner <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>>> On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> My interpretation is that he was advocating a future where a
>>>> precondition’s failure killed less than the entire process. Instead,
>>>> shut down some smaller portion like a thread, actor, or container
>>> 
>>>> like .Net's app domains (which for those more familiar with
>>>> Javascript could be loosely compared with Web Workers).
>>>> 
>>>> Today - if you wanted a Swift server where overflowing addition
>>>> didn’t interrupt your service for multiple users, you would need to
>>>> use something like a pre-fork model (with each request handled by a
>>>> separate swift process)
>>>> 
>>>> That's the difference between CLI and desktop apps where the process
>>>> is providing services for a single user, and a server where it may
>>>> be providing a service for thousands or millions of users.
>>> 
>>> Agreed, I’d also really like to see this some day.  It seems like a
>>> natural outgrowth of the concurrency model, if it goes the direction
>>> of actors.  
>>> 
>>> If you’re interested, I speculated on this direction in this talk:
>>> http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf <http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf>
>>> <http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf <http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf>>
>> 
>> I totally support the idea of emergency shutown measures
>> (e.g. save document for recovery), 
>> 
>> In general, though, when a precondition is violated, it means your
>> program state is compromised in an arbitrarily bad way.  Unfortunately,
>> that applies equally across process boundaries as it does across thread
>> boundaries, if there's some kind of static guarantee of safety as might
>> be provided by actors.  This means you need a way to make decisions
>> about which kinds of precondition violations should be considered
>> recoverable as long as you're willing to abandon the job, and which
>> really do need to be fatal for the whole process... and I don't know if
>> anyone's really ever figured that problem out.  It'd be cool if Swift
>> could solve it.
>> 
>> -- 
>> -Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170117/92ef40f9/attachment.html>