[swift-dev] [stdlib] Error recovery hook #12025

[Alex Blewitt]

One of the key reasons why you would want to handle those situations is that you may have a leak or other resources, but you may also be handling 99,999 other requests at the same time that you don't want to drop on the floor.

Even if you put the server into some kind of degraded mode (for example, taking it out of load balancer rotation) and let the requests drain naturally, it's still a lot better than terminating everything immediately.

This isn't an issue in single-user applications but when you have hundreds/thousands of simultaneous users it does limit where crashing the process makes sense.

(Of course, if the server really is deadlocked, then it's going to go down anyway; but if other parts can continue running then why not?)

Alex

> On 21 Sep 2017, at 18:53, Daniel Dunbar via swift-dev <swift-dev at swift.org> wrote:
> 
> It isn’t clear to me how much value this actually adds in a server domain. Inability to recover resources means you may immediate run into deadlocks, for example, so any robust server strategy will end up having to still handle that. If that machinery has to be in place regardless, why not use it for the existing error conditions.
> 
> Do you have any thoughts there?
> 
>  - Daniel
> 
>> On Sep 20, 2017, at 2:55 PM, John Holdsworth via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>> Hello Swift developers,
>> 
>> I’ve raised a rather speculative PR suggesting a hook be added to stdlib
>> that would allow users to experiment with error recovery in their apps.
>> 
>> https://github.com/apple/swift/pull/12025 <https://github.com/apple/swift/pull/12025>
>> 
>> Ultimately it come down to being able to do something like this:
>> 
>>             do {
>>                 try Fortify.exec {
>>                     var a: String!
>>                     a = a!
>>                 }
>>             }
>>             catch {
>>                 NSLog("Caught exception: \(error)")
>>             }
>> 
>> This was primarily intended for user in "Swift on the server" but could also
>> help avoid crashes in the mobile domain. The rationale and mechanics
>> are written up at the following url:
>> 
>> http://johnholdsworth.com/fortify.html <http://johnholdsworth.com/fortify.html>
>> 
>> I'll accept this won’t be everybody’s cup of tea but at this stage this is
>> only an opt-in facilitating patch. Developers need not subject their apps
>> to this approach which requires a separate experimental implementation.
>> 
>> The recovery is reasonably well behaved except it will not recover 
>> objects and system resources used in intermediate frames, It’s not
>> as random as something like, for example, trying to cancel a thread.
>> 
>> The debate about whether apps should try to soldier on when something
>> is clearly amiss is a stylistic one about which there will be a spectrum of
>> opinions. The arguments weigh more in favour in the server domain.
>> 
>> John
>> 
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170921/a592d20c/attachment.html>