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

[Xiaodi Wu]

We already have three ways of handling integer overflow:

+ traps
&+ overflows
addWithOverflow overflows and sets a flag if it does so

This supports all possible ways of handling the issue: you can trap, you
can get a result and not care about the overflow flag, or you can get the
result *and* the overflow flag. You can even discard the result and work
with only the flag.

I don't see how this doesn't meet exactly what you and Jonathan Hull
describe: it is opt-in, optional for callers, and does not propagate. It
doesn't require try or any other cumbersome syntax, and it allows you to
just compute the operation first and handle the overflow later only if it
occurs.

For array indexing, there is an outstanding proposal for more lenient
subscripts. In the meantime, you can trivially implement your own. Such a
facility would also behave according to your stated requirements.

On Tue, Jan 17, 2017 at 18:03 David Waite via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170118/22fcd8dd/attachment.html>