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

[Rien]

I am a bit ambivalent on this, on the one hand I think that “catch all, bring down thread only” stimulate careless programming, and on the other hand it did save my beacon on more than one occasion.

In a perfect world we should do without this kind of feature.

In the real world we need it to meet deadlines imposed by people who don’t understand software design….

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 17 Jan 2017, at 23:45, 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> wrote:
>> 
>> 
>> on Mon Jan 16 2017, Chris Lattner <swift-evolution at swift.org> wrote:
>> 
>>>> On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution
>>> <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>
>> 
>> 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
>> 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