[swift-users] "business applications market" flame

[Jeremy Pereira]

> On 6 Jan 2016, at 21:12, 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).

An API is a contract between the caller and callee. If you change it from non failable to failable, you are breaking the contract and likely introducing bugs into the code that calls it. As a consumer of your API, I absolutely do need to know if it has been changed to throw an error/exception just as much as I need to know if you add or remove parameters or change the return type.

The C# approach is brain dead in that, I have to assume every API can throw and put the error handling boiler plate in everywhere and the temptation is to ignore it. I think the Swift approach provides a much better balance.



> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users