<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 8, 2016, at 3:01 PM, Don Wills via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; 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; float: none; display: inline !important;" class="">The server needs to stay up, even in the face of latent bugs causing NullPointer exceptions and user-defined versions of similar errors.</span></div></blockquote></div><br class=""><div class="">Hold on. Swift doesn’t run in a virtual machine, doesn’t have a true garbage collector, and doesn’t (to my knowledge) have the same safety guarantees as “managed” languages like Java or C#. It’s a lot safer than C or C++, but buggy Swift programs can crash.</div><div class=""><br class=""></div><div class="">For example, my understanding is that dereferencing an implicitly-unwrapped optional (e.g. an “Int!”) that contains nil really does dereference a null pointer and causes a bus error. Otherwise every such dereference would have to have code in it to preflight the pointer, which is inefficient. Even if I’m wrong and Swift does preflight, it’s response is to trigger a fatalError that crashes the program. (Go is able to catch such a deref and turn it into a recoverable panic, but only because it installs a SIGBUS signal handler in the process, which is part of Go’s “we take over the entire process and do everything our way” philosophy.)</div><div class=""><br class=""></div><div class="">If you have a server process that needs to stay running even if modules fail, then you’ll probably have to run those modules as child processes and monitor them.</div><div class=""><br class=""></div><div class="">Again: apples and oranges.</div><div class=""><br class=""></div><div class="">I see now what you’re asking for, but you’ve been confusing matters by talking about checked vs. unchecked exceptions. As I’ve said many times, Swift has neither. What you want is basically a per-thread fatal error that terminates the thread but leaves the process running. Maybe this can be added in the future, but currently Swift has no intrinsic notion of threads so there’s nowhere to put such a mechanism.</div><div class=""><br class=""></div><div class="">—Jens</div></body></html>