<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="">On Jan 8, 2016, at 6:47 PM, Jens Alfke <<a href="mailto:jens@mooseyard.com" class="">jens@mooseyard.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div 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 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></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></blockquote><div><br class=""></div>My understanding of null references with forced unwrapping of optionals in Swift corresponds with what you say. But that's not what I am talking about. All I am asking for is that the "throws" keyword on a method definition be optional - that is, a method can throw a <thingy> with the throw statement without specifying "throws", and it can be caught by a matching try/catch clause up the stack. That is perfectly possible with LLVM and does not entail any ill-defined behavior. LLVM is capable of and well defined for supporting exactly what I'm looking for.</div><div><br class=""></div><div>You first sentence concerns me though. What "safety guarantees" does Swift lack that Java and C# have (other than possible memory leaks because of ARC)? Part of our communication problem is that I don't believe we agree on what the word "managed" means. To me it means "memory management", that is, garbage collection and dynamic class loaders. I suspect you are using it as per Microsoft's definition - a section of code that runs in the CLR that is type and pointer safe, vs. a section of code that is not (ie. "unmanaged"). FWIW, I believe that Microsoft's .NET/CLR is the only place in the computer industry that uses the word "managed" like that.<br class=""><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></blockquote><div><br class=""></div>That's really ugly and defeats the whole idea of GCD.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></blockquote><br class=""></div><div>A per-thread fatal error handler is not the answer though. A full fledged unchecked try/catch handler is what I am looking for, which can be implemented in Swift without any changes to LLVM.</div><div><br class=""></div><div>Don</div><div><br class=""></div><div>PS. I'll stop calling the object of a throw an exception. Words matter, and yes, Swift documentation does not use the word exception. It is unfortunate that Swift designers decided to use the keywords try, catch and throw and then decided to call what those statements deal with by a name that is different from all other programming languages, AFAIK.</div><br class=""></body></html>