[swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]
gparker at apple.com
Tue Jan 17 16:54:24 CST 2017
> On Jan 17, 2017, at 3:28 AM, Alex Blewitt via swift-evolution <swift-evolution at swift.org> wrote:
>> On 17 Jan 2017, at 11:10, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
>>> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolution <swift-evolution at swift.org> wrote:
>>> 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.
>> I don’t entirely agree for two reasons:
>> 1. If a runtime error is thrown and caught, there is no way to guarantee the logical consistency of the state of the running process because who knows which stack frames were unwound without cleaning up properly. There is no way to safely catch a run time exception and recover.
> From a Java perspective, clearly that's not true.
> It may well be true for the current implementation of Swift, and there's questions about how to clean up objects with reference counts outstanding (since there's no garbage collector). It isn't necessarily the case that it isn't possible, but it does require some additional stack unwinding; and the implementation of that may be too cumbersome/impractical/undesirable to occur.
Experience from ARC in Objective-C++ is that exception-safe reference counting costs a lot of code size and execution time. The threat of exceptions prevents many reference count optimizations.
Adding reference count operations to the unwind tables (e.g. DWARF) instead of using handler code to fix refcounts might help. Limiting the exception threat by using no-throw by default might help.
Greg Parker gparker at apple.com <mailto:gparker at apple.com> Runtime Wrangler
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution