<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I can see the appeal, but really throwable errors are just one kind of error that can happen in code.<div class=""><br class=""></div><div class="">Preconditions are a different thing. They represent axioms that must be kept for a sane program. It’s up to the programmer to decide whether something should be treated as an axiom or something recoverable. For a few particular operations (Array indexing, arithmetic), the standard library designers have decided that out-of-bounds values are to be considered axiom violations.</div><div class=""><br class=""></div><div class="">If that’s not convenient for your application, you could suggest changing the standard library to include throwing or optional-wrapped alternatives. You could also write your own:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Courier" class="">extension Array {</font></div><div class=""><font face="Courier" class=""> subscript(unchecked index: Index) -> Iterator.Element? { // Subscripts aren’t allowed to throw. There’s another proposal on that.</font></div><div class=""><font face="Courier" class=""> guard (startIndex..<endIndex).contains(index) else { return .none }</font></div><div class=""><font face="Courier" class=""> return self[index]</font></div><div class=""><font face="Courier" class=""> }</font></div><div class=""><font face="Courier" class="">}</font></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><font face="Courier" class="">let array = [1,2,3,4]</font></div><div class=""><font face="Courier" class="">array[unchecked: 99] // Returns nil</font></div><div class=""><font face="Courier" class="">array[unchecked: 0] // Returns 1</font></div></blockquote><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 12 Jan 2017, at 23:58, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I really like swift’s error handling system overall. It strikes a good balance between safety and usability.<br class=""><br class="">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.<br class=""><br class="">I would like to propose adding ‘throws?’ and ‘throws!’ variants to ‘throws’.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">I think this would really increase the availability of error handling in areas where it is impractical right now…<br class=""><br class="">Thanks,<br class="">Jon<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>