<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">Namely, all of the following would then be valid:</div><div class=""><div style="word-wrap: break-word;" class=""><pre style="color: inherit; margin-top: 15px; margin-bottom: 15px; font-family: Menlo, Consolas, 'Liberation Mono', Courier, monospace; font-size: 10pt; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248); border: 1px solid rgb(204, 204, 204); overflow: auto; padding: 4px 8px; word-break: normal; word-wrap: normal;" class="">// Explicitly declared to throw, but doesn't have to be caught
func runtimeThrowingFunc1() throws {
throw SubclassOfRuntimeException
}
<span class=""><br class="">// Not e</span><span style="color: inherit; font-size: 10pt;" class="">xplicitly declared to throw, and doesn't have to be caught</span><span class=""><div class="">func runtimeThrowingFunc2() {</div><div class=""> throw SubclassOfRuntimeException</div><div class="">}</div>
// Doesn't have to be caught...<br class=""></span><span class="">runtimeThrowingFunc1()
do {
// But you can if you want
try runtimeThrowingFunc1()
} catch (SubclassOfRuntimeException) {
} catch (RuntimeException) {
}
</span><span class="">// Doesn't have to be caught...<br class=""><div class="">runtimeThrowingFunc2()</div><div class="">do {</div><div class=""> // But you can if you want</div><div class=""> try runtimeThrowingFunc2()</div><div class="">} catch (SubclassOfRuntimeException) {</div><div class="">} catch (RuntimeException) {</div><div class="">}</div></span></pre></div></div><div class=""><div class="">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.</div><div class=""><br class=""></div><div class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">-thislooksfun (tlf)</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Jan 16, 2017, at 7:59 PM, Kenny Leung via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">It would also enable the testing of fatal conditions, which would be great.</div><div class=""><br class=""></div><div class="">-Kenny</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 16, 2017, at 5:25 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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).<div class=""><br class=""></div><div class="">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)</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">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:</div><div class=""><a href="http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf" class="">http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf</a></div><div class=""><br class=""></div><div class="">-Chris</div></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>