[swift-users] "business applications market" flame

[Jens Alfke]

> On Jan 8, 2016, at 3:01 PM, Don Wills via swift-users <swift-users at swift.org> wrote:
> 
> The server needs to stay up, even in the face of latent bugs causing NullPointer exceptions and user-defined versions of similar errors.

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.

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.)

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.

Again: apples and oranges.

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.

—Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160108/1c9c5dbe/attachment.html>