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.
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:
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.
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@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.
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:
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.
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@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@swift.org <mailto:swift-dev@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.
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:
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.
There's a thread for this topic on swift-evolution. It'd be good to keep the discussion focused there.
-Joe
···
On Sep 21, 2017, at 11:01 AM, Alex Blewitt via swift-dev <swift-dev@swift.org> wrote:
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?)