What is the difference between Swift 2.0 do-try-catch and regular Java/C#/C++ exceptions

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.

  • Use of unresolved identifier when using StoreKit constants with iOS 9.3/Xcode 7.3
  • xcode error : Cannot call value of non-function type module Firebase
  • Load more options with UITableView
  • UIButton in Swift 2.2. How to add different target?
  • swift: async task + completion
  • com.apple.product-type.bundle.ui-testing, but there's no such product type for the 'iphonesimulator' platform
  • 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).

    Solutions Collect From Internet About “What is the difference between Swift 2.0 do-try-catch and regular Java/C#/C++ exceptions”

    There are 3 major differences I have found:

    1. It is not necessary to list all errors a function can throw, only a throws keyword is needed.

    2. There is no significant slowdown when using these errors, while Java and other languages need to construct an Exception object and unwind the stack. In Swift a throws keyword can be viewed as the function returning an Either-object, with one being the original return type, and the other being an ErrorType value.

    3. 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”)