I’m not sure I like this specific proposal, but the idea of having the option of catching a certain class of runtime errors is appealing.
I don’t think it makes sense to abort a server process (potentially dropping X threads and thousands of connections on the ground) because one stray thread performed an overflowing addition… one could always require use of addWithOverflow I suppose, but auditing code for “+” is a different kind of pain than auditing for UnsafeMutablePointer. For servers the operation is almost always bounded by a single request, so unwinding any transactions and aborting the thread is sufficient to recover. There will also be cases where cleanup on fatalError() is absolutely required; if Swift leaves dangling database transactions on abort it is not usable for a large number of scenarios (speaking from direct experience). Rust takes an interesting approach with panic and catch_unwind… at compile time you can make a policy decision that all panics are aborts or that non-catastrophic panics can be handled, but only by the parent thread. In our terminology that would be saying that precondition ends the current dispatch work item and only the parent queue can handle the failure. This gets very tricky to even describe because it doesn’t map cleanly to libDispatch and we don’t have the compiler support to enforce cross-queue boundaries right now, so there is the potential to leak memory (which is OK for infrequent panics) or corrupt memory (unacceptable). My guess is we could do something like this and in fact will need to do something like this, but only when we have a good concurrency story enforced by the compiler. Russ > On Jan 12, 2017, at 2:58 PM, Jonathan Hull via swift-evolution > <swift-evolution@swift.org> wrote: > > I really like swift’s error handling system overall. It strikes a good > balance between safety and usability. > > There are some cases where it would be nice to throw errors, but errors are > rarely expected in most use cases, so the overhead of ‘try’, etc… would make > things unusable. Thus fatalError or optionals are used instead. For example, > operators like ‘+’ could never throw because adding ’try’ everywhere would > make arithmetic unbearable. But in a few cases it would make my algorithm > much cleaner if I just assume it will work and then catch overflow/underflow > errors if they happen, and resolve each of them with special cases. Or > perhaps I am dealing with user entered values, and want to stop the > calculation and display a user visible error (e.g. a symbol in a spreadsheet > cell) instead of crashing. > > I would like to propose adding ‘throws?’ and ‘throws!’ variants to ‘throws’. > > These would be used for cases where error handling is not the default desired > behavior, but having it as an option is desired occasionally. Essentially, > the user would no longer have to preface the call with ‘try’, as the compiler > would implicitly add ‘try?’ or ‘try!’ respectively. > > Thus, the function would act like a non-throwing function (either trapping or > returning an optional in the case of error), but the user could add ‘try’ to > the call to override that behavior and deal with the error more explicitly. > > Another example would be bounds checking on arrays. If subscripting arrays > was marked as ‘throws!’ then it would have the same default behavior it does > now (trapping on bounds error). But a user could add ‘try?’ to return nil > for a bounds error in cases where they explicitly want that, or they could > add ‘try’ to deal with it as an error using do-catch. > > I think this would really increase the availability of error handling in > areas where it is impractical right now… > > Thanks, > Jon > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
