[swift-users] "business applications market" flame

[Jens Alfke]

> On Jan 6, 2016, at 11:40 AM, Jeremy Pereira via swift-users <swift-users at swift.org> wrote:
> 
> In Swift, you throw errors, not exceptions. The word exception is (more or less) reserved for conditions that terminate the process. 
> 
> There are no unchecked errors but then why would you not want to handle an error condition if it occurs? Why would you not want to know that an API can throw an error?

The bigger point is that in Swift you always know at the call site whether something can fail. That is, you can see the possible flows of control by inspecting the code. 

Consider this block of code:
	{ foo(); bar(); endFoo(); }
If foo is called, will endFoo() also be called? 

In C++/Java/C# it’s not possible to tell without doing extensive analysis of the implementation of bar (and everything that bar calls), because bar might throw an exception and derail this flow of control. (And worse, some later code change far away might add an unchecked exception, making your analysis wrong!) This then requires adding noise in the form of a ‘finally’ block or a helper class implementing RAII, if it’s really important that endFoo be called. In a lot of cases this is “too much trouble” so a lot of code gets left like above, and will break some invariant if the endFoo call gets skipped.

In Swift you can be sure that, if this block is entered, all three functions will be called. (Unless the process hits a fatal exception like an assertion failure or bus error and exits.) If it’s possible for bar to fail, then
(a) the call to bar will have to be prefixed with ‘try’, which is a yellow flag to the programmer noting the possibility*; and
(b) the block will have to be inside a `do … catch` block, in the same function, to handle the error. An error in bar() can’t just abort the function silently. Any cleanup that has to be done will be explicit.

—Jens

* 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160106/aa8462c7/attachment.html>