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

On Sat, 21 Jan 2017 at 10:35 am, Jean-Daniel wrote: > > > > Le 20 janv. 2017 à 22:55, Howard Lovatt via swift-evolution < > swift-evolution@swift.org> a écrit : > > > > > > In Java there is a hierarchy of errors, the idea is that you catch at > different severities. It

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

> Le 20 janv. 2017 à 22:55, Howard Lovatt via swift-evolution > a écrit : > > In Java there is a hierarchy of errors, the idea is that you catch at > different severities. It isn't particularly well implemented in Java with a > weird hierarchy and errors strangely

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

In Java there is a hierarchy of errors, the idea is that you catch at different severities. It isn't particularly well implemented in Java with a weird hierarchy and errors strangely classified and poor naming. Despite these glaring shortcoming it does actually work! In Swift this general

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

On Jan 18, 2017, at 10:45 AM, John McCall via swift-evolution wrote: >> >> That's certainly true of code that makes unaudited use of `unsafe` >> constructs that can violate safety without any checking. It's my hope that >> our normal safety checks are thorough and

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

> On Jan 18, 2017, at 9:06 AM, Joe Groff via swift-evolution > wrote: >> On Jan 18, 2017, at 12:04 AM, Rien via swift-evolution >> wrote: >> >>> >>> On 18 Jan 2017, at 08:54, Jonathan Hull via swift-evolution >>>

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

on Tue Jan 17 2017, Jonathan Hull wrote: >> On Jan 17, 2017, at 7:13 PM, Dave Abrahams wrote: >> >> >> on Tue Jan 17 2017, Jonathan Hull > > wrote: >> > >>> Bringing it back towards the initial post, what if there was a >>> separation from

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

> On Jan 18, 2017, at 12:04 AM, Rien via swift-evolution > wrote: > >> >> On 18 Jan 2017, at 08:54, Jonathan Hull via swift-evolution >> wrote: >> >> >>> On Jan 17, 2017, at 7:13 PM, Dave Abrahams wrote: >>> >>>

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

> On 17 Jan 2017, at 11:53, Alex Blewitt wrote: > >> >> On 17 Jan 2017, at 11:46, Jeremy Pereira >> wrote: >> >>> >>> On 17 Jan 2017, at 11:28, Alex Blewitt wrote: >>> >>> On 17 Jan 2017, at 11:10, Jeremy Pereira

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

> On 18 Jan 2017, at 08:54, Jonathan Hull via swift-evolution > wrote: > > >> On Jan 17, 2017, at 7:13 PM, Dave Abrahams wrote: >> >> >> on Tue Jan 17 2017, Jonathan Hull wrote: >> >>> Bringing it back towards the initial post, what if

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

> On Jan 17, 2017, at 7:13 PM, Dave Abrahams wrote: > > > on Tue Jan 17 2017, Jonathan Hull > 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

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

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

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

on Tue Jan 17 2017, Jonathan Hull 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

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

> On Jan 17, 2017, at 1:38 PM, Dave Abrahams via swift-evolution > wrote: > > It also means, from a purely pragmatic view, that control flow for > things that are really not reliably recoverable conditions (like index > out-of-range) is not cleanly separated from

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

On Tue, Jan 17, 2017 at 6:50 PM, Jonathan Hull wrote: > I rewrote some code which used NSDecimalNumber to use Decimal and it went > from 20 lines of hard to follow code to 2 lines of easy to follow > expressions. ‘2+2’ is much easier to understand at a glance than having a >

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

I rewrote some code which used NSDecimalNumber to use Decimal and it went from 20 lines of hard to follow code to 2 lines of easy to follow expressions. ‘2+2’ is much easier to understand at a glance than having a sentence for each operation. Also the control flow is completely different.

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

We already have three ways of handling integer overflow: + traps &+ overflows addWithOverflow overflows and sets a flag if it does so This supports all possible ways of handling the issue: you can trap, you can get a result and not care about the overflow flag, or you can get the result *and*

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

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

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

> On Jan 17, 2017, at 3:28 AM, Alex Blewitt via swift-evolution > wrote: > >> On 17 Jan 2017, at 11:10, Jeremy Pereira via swift-evolution >> wrote: >> >>> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolution >>>

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

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

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

on Tue Jan 17 2017, Joe Groff wrote: >> On Jan 17, 2017, at 3:53 AM, Alex Blewitt via swift-evolution > wrote: >> >>> >>> On 17 Jan 2017, at 11:46, Jeremy Pereira >>> >>>

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

on Mon Jan 16 2017, Chris Lattner wrote: >> On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution > wrote: >> >> My interpretation is that he was advocating a future where a >> precondition’s failure killed less than the entire

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

> On Jan 17, 2017, at 3:53 AM, Alex Blewitt via swift-evolution > wrote: > >> >> On 17 Jan 2017, at 11:46, Jeremy Pereira > > wrote: >> >>> >>> On 17 Jan 2017, at 11:28, Alex Blewitt

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

> On 17 Jan 2017, at 11:46, Jeremy Pereira > wrote: > >> >> On 17 Jan 2017, at 11:28, Alex Blewitt wrote: >> >> >>> On 17 Jan 2017, at 11:10, Jeremy Pereira via swift-evolution >>> wrote: >>> >>> On 17

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

> On 17 Jan 2017, at 11:28, Alex Blewitt wrote: > > >> On 17 Jan 2017, at 11:10, Jeremy Pereira via swift-evolution >> wrote: >> >> >>> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolution >>> wrote: >>> >>> I

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

> On 17 Jan 2017, at 11:10, Jeremy Pereira via swift-evolution > wrote: > > >> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolution >> wrote: >> >> I really hate to bring Java up, but I really do think it got at least one >>

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

> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolution > wrote: > > I really hate to bring Java up, but I really do think it got at least one > thing right with its error system, namely that one subset of error (namely > `RuntimeException`), wouldn't be

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

I really hate to bring Java up, but I really do think it got at least one thing right with its error system, namely that one subset of error (namely `RuntimeException`), wouldn't be enforced by the compiler, but could optionally be caught. Namely, all of the following would then be valid: //

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

It would also enable the testing of fatal conditions, which would be great. -Kenny > On Jan 16, 2017, at 5:25 PM, Chris Lattner via swift-evolution > wrote: > > >> On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution >>

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

> On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution > 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