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

Daniel Dunbar daniel_dunbar at apple.com
Thu Sep 21 12:53:07 CDT 2017


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> 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
> 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/36930576/attachment.html>


More information about the swift-dev mailing list