I can see the appeal, but really throwable errors are just one kind of error
that can happen in code.
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.
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:
extension Array {
subscript(unchecked index: Index) -> Iterator.Element? { //
Subscripts aren’t allowed to throw. There’s another proposal on that.
guard (startIndex..<endIndex).contains(index) else { return .none }
return self[index]
}
}
let array = [1,2,3,4]
array[unchecked: 99] // Returns nil
array[unchecked: 0] // Returns 1
> On 12 Jan 2017, at 23:58, Jonathan Hull via swift-evolution
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
