[swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

[David Waite]

> On Jan 17, 2017, at 1:38 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> It also means, from a purely pragmatic view, that control flow for
> things that are really not reliably recoverable conditions (like index
> out-of-range) is not cleanly separated from control flow for handling
> recoverable things like dropped network conditions, so it can be really
> hard to know that you're reliably shutting down the program when you
> should, and that's not being subverted by some general “recovery” code.

Agreed. The “try” syntax is part of a decision to use errors to represent conditions recoverable by business logic. This might be a network connection closed, but shouldn’t be used for conditions like memory allocation failed, a KILL signal, or detection of corrupted data within an application bundle.

In the middle are avoidable runtime errors like array indexing out-of-bounds and math overflow. Some business logic might care about these, in particular logic which deals with arbitrary user input. However, using ‘try’ syntax would result in both an explosion of needing to specify try in expressions, and in errors which can’t really be recovered in typical business logic.

I see this as three regions of error conditions - system level errors that the developer isn’t expected to try and recover from, application-level errors that the developer is likely going to want to control the behavior of, and in between the runtime errors which some logic might care about, but which in most cases should be treated as a system level error.

Java roughly has Error, Exception, and RuntimeException to correspond to these, with a few differences which I generally consider to be flaws in the Java language (RuntimeException is under Exception, RuntimeExceptions percolate up the entire stack rather than being escalated to Errors if unhandled).

I can envision a future state where:
- system level errors can have atexit/terminate-style shutdown hooks. These do not support recovery, but can be used to attempt a cleaner shutdown
- functions which emit runtime errors (such as math overflow) can support a call form which returns an error rather than precondition failure, but it is opt in and optional for callers. The runtime errors do not propagate automatically, and callers which do not request it get precondition failures
- the possibility of containerization so that runtime errors and certain system level errors terminate a thread/actor/app domain rather than the whole process

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170117/3d7243d8/attachment.html>