[swift-users] "business applications market" flame

[Brent Royal-Gordon]

>>>> IMO, Java has it right - let the API designer decide which approach to take.
>>> 
>>> That's a frankly laughable misreading of the Java story. The Java story is that they wanted everyone to use checked exceptions, but the users loathed them so much that they found hacks to get around the checked exception system
> 
> Do you really believe that you can stop the "users" who "loathed them so much" from doing what they want to do with Swift?  Hubris isn't a strong enough word to describe that attitude.

No, but I think we can design a system that fewer users will hate so much that they actively seek to thwart it. That's why Swift has you mark throwing functions, but doesn't make you declare which errors they can throw—this is seen as a good balance between the anything-goes world of unchecked exceptions and the annoyingly-specific world of checked exceptions.

> FWIW, I've already started down the path of dealing with the lack of unchecked <whatever-you-call-em>s by using the following code:
> 
> func add(p1: String, _ p2 Any) {
>     try! addWithThrows(p1, p2)
> }
> 
> private func addWithThrows(p1: String, _ p2 Any) throws {
>     // code that handles many types for p2, followed by return for each of the valid types
>     throw Exception("Invalid type")  /* for those types not supported which is a programmer error */
> }
> 
> public class Exception: ErrorType {
>     init() {
>     }
>     init(_ msg: String) {
>     }
> }

That's great! You're clearly indicating that addWithThrows(_:_:) can throw, and at the call site you assert non-failure. This may not be the best way to handle errors—a more descriptive ErrorType and some do/catch code could probably give a better error experience, or if all errors should crash you could just use precondition()—but that's your choice. What's important is that the error-handling behavior of your code is obvious to anyone who reads it.

> You can laugh all you at my OPINION about Java's checked and unchecked, but in the end, the great unwashed masses of programmers do whatever they believe is best to build their software, regardless of what programming languages designers believe or try to force upon them.

"Laughable" was unkind; I apologize for using that word. What I was trying to get at was that Java's designers never intended for users to use unchecked exceptions very often—this was an unintended consequence of their design.

The design of the language inescapably shapes the code written in it, though not always in the direction the language's designers intend. Java's design was intended to shape code into robustly handling errors; instead, it shaped code to circumvent its safety checks and ignore errors. Swift is trying to learn from those mistakes, by using a less burdensome form of checked errors, and by making it easier to crash when there's an error (using `try!`) than ignore an error (using an empty `catch` clause).

Undoubtedly some people will still find ways to use Swift's error system in unintended ways, but hopefully they will do so less often than they would if we had slavishly copied another language's error handling.

-- 
Brent Royal-Gordon
Architechies