[swift-evolution] Throws? and throws!

[Kevin Nattinger]

> On Jan 12, 2017, at 3:50 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Some additional thoughts: if I recall correctly from my (limited) Java days, throwing in Java worked essentially like your proposed `throws!`. That the Swift model expressly deviates from that example was not by accident, as far as I can tell. According to the error handling docs in the Swift repo:

Java (functionally) has two types of exceptions, checked and unchecked. 
Checked exceptions must either be caught and handled or the calling method must be declared as throwing the same exception (or an ancestor).
Unchecked exceptions do not need to be declared, and can either be caught or implicitly work their way back up the stack until either they’re caught or they hit the top of the stack (in which case the JRE kills the program.

Objective-C’s exception system is essentially Java’s unchecked type, and Swift’s is checked (with the addition of requiring `try` at the call site. At risk of getting off on a tangent, I really dislike the raw `try` requirement. `try?` and `try!` at least make sense as they specify how to handle the exception; `try` does not.)
Swift’s exception system is basically checked exceptions; Objective-C’s is unchecked.

As far as I can tell, this proposal isn’t really like either; `throws?` would swallow the exception entirely if the caller didn’t handle it and `throws!` would kill the app without giving higher stack frames a chance to catch it. I’m really not a fan of either; I’d much prefer unchecked exceptions, and I think they fulfill the OP’s underlying concerns.

> 
> "Once an error is thrown, Swift will automatically propagate it out of scopes (that permit it), rather than relying on the programmer to manually check for errors and do their own control flow. This is just a lot less boilerplate for common error handling tasks. However, doing this naively would introduce a lot of implicit control flow, which makes it difficult to reason about the function's behavior. This is a serious maintenance problem and has traditionally been a considerable source of bugs in languages that heavily use exceptions.
> 
> "Therefore, while Swift automatically propagates errors, it requires that statements and expressions that can implicitly throw be marked with the `try` keyword."
> 
> So I think what this is saying is that requiring `try` _every time_ is core to the design of Swift error handling, and that `throws!` or even `throws?` would undo it.
> 
> 
> On Thu, Jan 12, 2017 at 5:35 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
> On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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.
> 
> Unless I'm mistaken, there is a performance overhead for throwing functions, and thus a much greater barrier to the use cases outlined above is that the performance penalty for '+' would be unacceptable in any case, whatever syntactic sugar you could come up with.
>  
> 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.
> 
> While I admit the idea has an appeal on a practical level, I have an uncomfortable feeling about this. It's by definition true that error handling is never the default desired behavior, and if I recall correctly the performance of Swift error handling is tuned on the assumption that not throwing is far more common than throwing. If we accept this statement at face value as the justification for including `throws!`, then essentially all `throws` should be `throws!`. And indeed I suspect that if the feature were be implemented, that would rapidly become the case in much written Swift. In essence, then, I think you're effectively proposing to invert the assignment of responsibility for determining how errors are handled from the call site to the declaration site, at least by default. It goes against an overarching design principle in Swift (discussed earlier in the thread about DefaultConstructible) not to provide such defaults and to require explicitness at the call site.
> 
> 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.
> 
> Subscripts cannot throw at all at the moment, and in another thread some of the challenges for designing throwing subscripts were just mentioned. I suspect any sort of throwing subscript will not be possible in the immediate future, so the argument for `throws!` here is moot.
> 
> I think this would really increase the availability of error handling in areas where it is impractical right now…
> 
> I think the practical argument could be made stronger by use cases not encumbered by other difficulties as outlined above. Is there a currently throwing function you've encountered that would be greatly improved by such a feature? Besides that, though, my discomfort is (as mentioned above) that the practical effect of such a feature is that it will actually altogether invert the default responsibility for error handling, and I'm not sure that it's entirely consistent with Swift's design as a consequence. In any case it'd be a far greater change than you've made it out to be. Interesting suggestion, definitely.
> 
> Thanks,
> Jon
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> 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/20170112/aa4417bc/attachment.html>