[swift-users] "business applications market" flame

[Greg Parker]

> On Jan 6, 2016, at 1:12 PM, Don Wills via swift-users <swift-users at swift.org> wrote:
> 
>> On Jan 6, 2016, at 1:15 PM, Jens Alfke <jens at mooseyard.com> wrote:
>> 
>> * The requirement of the ‘try’ prefix means that if a function that isn’t failable later gets modified to be failable, every call site will now trigger a compile error due to the missing ‘try’ keyword. This means the programmer who made the change will have to go through the codebase and consider the possibility of failure and adjust the call site accordingly. This is a really good thing!
> 
> It also means that every third party API provider will *never* be able to change any method signature from failable to non-failable or vice-versa.  That is a really bad thing!  This concern is why Microsoft rightly chose to have *only* non-checked exceptions in C# (Java has both checked and non-checked).

Swift's error system does put some burden on careful API design. The API author does need to choose "throwing" vs "not throwing" correctly up front.

On the other hand, the API author does not need to predict *which* errors might be thrown in the future. That avoids most of the difficulty for most API.

The API author's loss is the API client's gain. For anything that does not throw, the API client does not need to defensively assume that everything could throw in the future. This is good because writing exception-safe code is hard, especially if you can't test it.

We decided this was the right distribution of pain. The API author needs to plan ahead a little bit (but not as much as in a pure checked-exception system). The API client is safe almost everywhere against the threat of unusual control flow, and the presence of unusual control flow is always marked `try` when it is necessary.


-- 
Greg Parker     gparker at apple.com     Runtime Wrangler