Noobass Noobass - 1 year ago 53
Swift Question

Why is throws not type safe in Swift?

The biggest misunderstanding for me in Swift is the

keyword. Consider the following piece of code:

func myUsefulFunction() throws

We cannot really understand what kind of error it will throw. The only thing we know is that it might throw some error. The only way to understand what the error might be is by looking at the documentation or checking the error at runtime.

But isn't this against Swift's nature? Swift has powerful generics and a type system to make the code expressive, yet it feels as if
is exactly opposite because you cannot get anything about the error from looking at the function signature.

Why is that so? Or have I missed something important and mistook the concept?

Answer Source

The choice is a deliberate design decision.

They did not want the situation where you don't need to declare exception throwing as in Objective-C, C++ and C# because that makes callers have to either assume all functions throw exceptions and include boilerplate to handle exceptions that might not happen, or to just ignore the possibility of exceptions. Neither of these are ideal and the second makes exceptions unusable except for the case when you want to terminate the program because you can't guarantee that every function in the call stack has correctly deallocated resources when the stack is unwound.

The other extreme is the idea you have advocated and that each type of exception thrown can be declared. Unfortunately, people seem to object to the consequence of this which is that you have large numbers of catch blocks so you can handle each type of exception. So, for instance, in Java, they will throw Exception reducing the situation to the same as we have in Swift or worse, they use unchecked exceptions so you can ignore the problem altogether. The GSON library is an example of the latter approach.

We chose to use unchecked exceptions to indicate a parsing failure. This is primarily done because usually the client can not recover from bad input, and hence forcing them to catch a checked exception results in sloppy code in the catch() block.

That is an egregiously bad decision. "Hi, you can't be trusted to do your own error handling, so your app should crash instead".

Personally, I think Swift gets the balance about right. You have to handle errors but you don't have to write reams of catch statements to do it. If they went ny further, people would find ways to subvert the mechanism.

The full rationale for the design decision is at

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download