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