Re: [swift-evolution] Throws? and throws!

One stray thread performing an overflowing addition can be the difference between a secure system and an insecure one. Better to take the process down. -- Callionica On Sun, Jan 15, 2017 at 10:48 PM Russ Bishop via swift-evolution < swift-evolution@swift.org> wrote: > > > I don’t think it makes

Re: [swift-evolution] Throws? and throws!

> My intended framing of this does not seem to be coming across in my > arguments. I am not thinking of this as a way to avoid typing ‘try!’ or > ‘try?’. This is not intended to replace any of the current uses of ‘throws’. > Rather, it is intended to replace trapping and nil-returning

Re: [swift-evolution] Throws? and throws!

I’m not sure I like this specific proposal, but the idea of having the option of catching a certain class of runtime errors is appealing. I don’t think it makes sense to abort a server process (potentially dropping X threads and thousands of connections on the ground) because one stray thread

Re: [swift-evolution] Throws? and throws!

On Sun, Jan 15, 2017 at 3:12 PM, Haravikk wrote: > > On 12 Jan 2017, at 23:35, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > >> I

Re: [swift-evolution] Throws? and throws!

> On 12 Jan 2017, at 23:35, Xiaodi Wu via swift-evolution > > wrote: > > On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution > > wrote: > I really like

Re: [swift-evolution] Throws? and throws!

On Sat, Jan 14, 2017 at 10:10 PM, Jonathan Hull wrote: > And finally, even if an operator function could fail in multiple ways > (we're really getting to very hypothetical hypotheticals here), writing > `try!` all the time might look silly and non-Swift users might then mock >

Re: [swift-evolution] Throws? and throws!

> And finally, even if an operator function could fail in multiple ways (we're > really getting to very hypothetical hypotheticals here), writing `try!` all > the time might look silly and non-Swift users might then mock the language, > but I dispute the contention that it would make things

Re: [swift-evolution] Throws? and throws!

On Sat, Jan 14, 2017 at 8:03 PM, Jonathan Hull wrote: > My intended framing of this does not seem to be coming across in my > arguments. I am not thinking of this as a way to avoid typing ‘try!’ or > ‘try?’. This is not intended to replace any of the current uses of > ‘throws’.

Re: [swift-evolution] Throws? and throws!

My intended framing of this does not seem to be coming across in my arguments. I am not thinking of this as a way to avoid typing ‘try!’ or ‘try?’. This is not intended to replace any of the current uses of ‘throws’. Rather, it is intended to replace trapping and nil-returning functions

Re: [swift-evolution] Throws? and throws!

> On 13 Jan 2017, at 17:10, Joe Groff via swift-evolution > wrote: > > >> On Jan 12, 2017, at 2:58 PM, Jonathan Hull via swift-evolution >> wrote: >> >> I really like swift’s error handling system overall. It strikes a good >> balance

Re: [swift-evolution] Throws? and throws!

> On Jan 12, 2017, at 2:58 PM, Jonathan Hull via swift-evolution > wrote: > > I really like swift’s error handling system overall. It strikes a good > balance between safety and usability. > > There are some cases where it would be nice to throw errors, but errors

Re: [swift-evolution] Throws? and throws!

I can see the appeal, but really throwable errors are just one kind of error that can happen in code. Preconditions are a different thing. They represent axioms that must be kept for a sane program. It’s up to the programmer to decide whether something should be treated as an axiom or

Re: [swift-evolution] Throws? and throws!

-1 I think the basic type system should remain free of such constructs. I.e. if a Throws? is necessary on a + operation between integers, then the integers should be encapsulated into their own type. In fact I am thinking lately of the “need” for a new type system in parallel to the current

Re: [swift-evolution] Throws? and throws!

> On Jan 12, 2017, at 5:34 PM, Greg Parker via swift-evolution > wrote: > > >> On Jan 12, 2017, at 4:46 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >>> On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull

Re: [swift-evolution] Throws? and throws!

On Thu, Jan 12, 2017 at 7:34 PM, Greg Parker wrote: > > On Jan 12, 2017, at 4:46 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull wrote: > > > Also, ‘try’ is still required to explicitly

Re: [swift-evolution] Throws? and throws!

> On Jan 12, 2017, at 4:46 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull > > wrote: >> >> Also, ‘try’ is still required to explicitly mark a potential error >> propagation

Re: [swift-evolution] Throws? and throws!

On Thu, Jan 12, 2017 at 6:17 PM, Jonathan Hull wrote: > > On Jan 12, 2017, at 3:35 PM, Xiaodi Wu wrote: > > On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > >> I really like swift’s error handling

Re: [swift-evolution] Throws? and throws!

On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull wrote: > The problem with Java (and ObjC) is that exceptions can propagate > unexpectedly into scopes which they weren’t expected and you end up with > objects in inconsistent states where it is nearly impossible to continue in > any

Re: [swift-evolution] Throws? and throws!

On Thu, Jan 12, 2017 at 6:17 PM, Jonathan Hull wrote: > > On Jan 12, 2017, at 3:35 PM, Xiaodi Wu wrote: > > On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > >> I really like swift’s error handling

Re: [swift-evolution] Throws? and throws!

The problem with Java (and ObjC) is that exceptions can propagate unexpectedly into scopes which they weren’t expected and you end up with objects in inconsistent states where it is nearly impossible to continue in any meaningful way. That can’t happen here as the error will never propagate

Re: [swift-evolution] Throws? and throws!

> On Jan 12, 2017, at 3:50 PM, Xiaodi Wu via swift-evolution > wrote: > > Some additional thoughts: if I recall correctly from my (limited) Java days, > throwing in Java worked essentially like your proposed `throws!`. That the > Swift model expressly deviates from

Re: [swift-evolution] Throws? and throws!

> On Jan 12, 2017, at 3:35 PM, Xiaodi Wu wrote: > > On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution > > wrote: > I really like swift’s error handling system overall. It strikes a good >

Re: [swift-evolution] Throws? and throws!

Some additional thoughts: if I recall correctly from my (limited) Java days, throwing in Java worked essentially like your proposed `throws!`. That the Swift model expressly deviates from that example was not by accident, as far as I can tell. According to the error handling docs in the Swift

Re: [swift-evolution] Throws? and throws!

On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > I really like swift’s error handling system overall. It strikes a good > balance between safety and usability. > > There are some cases where it would be nice to throw errors, but errors > are

[swift-evolution] Throws? and throws!

I really like swift’s error handling system overall. It strikes a good balance between safety and usability. There are some cases where it would be nice to throw errors, but errors are rarely expected in most use cases, so the overhead of ‘try’, etc… would make things unusable. Thus fatalError