Question or problem in the Swift programming language:
It seems that Swift 2.0 has changed from traditional ObjC (NSError returning) and Swift 1.X (Success/Failure optionals) conventions of runtime error handling, to something that looks very similar to exception handling in languages like Java/C#/C++/etc.
Apple has traditionally emphasized use of NSError instead of throwing NSException for runtime errors (vs programmer errors), as NSException stack unwinding could cause memory leaks with default ObjC compiler settings.
Now they have however devised something that looks very, very similar to traditional exceptions. My question is:
Are there any real differences between Swift 2.0 error handling and traditional exception handling beside nomenclature (error vs exception) and syntax (do-catch, instead of try-catch, try used before method call, etc).
How to solve the problem:
There are 3 major differences I have found:
It is not necessary to list all errors a function can throw, only a
throwskeyword is needed.
There is no significant slowdown when using these errors, while Java and other languages need to construct an
Exceptionobject and unwind the stack. In Swift a
throwskeyword can be viewed as the function returning an
Either-object, with one being the original return type, and the other being an
In Swift all errors need to be handled or declared to be thrown, it is impossible to get an error from a method that does not state it is throwing an error. (in Java terms, all errors are “checked exceptions”)