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:
// Explicitly declared to throw, but doesn't have to be caught
func runtimeThrowingFunc1() throws {
  throw SubclassOfRuntimeException
}

// Not explicitly declared to throw, and doesn't have to be caught
func runtimeThrowingFunc2() {
  throw SubclassOfRuntimeException
}

// Doesn't have to be caught...
runtimeThrowingFunc1()
do {
  // But you can if you want
  try runtimeThrowingFunc1()
} catch (SubclassOfRuntimeException) {
} catch (RuntimeException) {
}

// Doesn't have to be caught...
runtimeThrowingFunc2()
do {
  // But you can if you want
  try runtimeThrowingFunc2()
} catch (SubclassOfRuntimeException) {
} catch (RuntimeException) {
}
I'm not advocating explicitly for this model, it is based on Java's exception 
system after all, but it think it's a place to start at the very least.

-thislooksfun (tlf)

> On Jan 16, 2017, at 7:59 PM, Kenny Leung via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 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 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@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>
>> 
>> -Chris
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to