Swift do-try-catch syntax

I suspect this just hasn’t been implemented properly yet. The Swift Programming Guide definitely seems to imply that the compiler can infer exhaustive matches 'like a switch statement'. It doesn’t make any mention of needing a general catch in order to be exhaustive.

You'll also notice that the error is on the try line, not the end of the block, i.e. at some point the compiler will be able to pinpoint which try statement in the block has unhandled exception types.

The documentation is a bit ambiguous though. I’ve skimmed through the ‘What’s new in Swift’ video and couldn’t find any clues; I’ll keep trying.

Update:

We’re now up to Beta 3 with no hint of ErrorType inference. I now believe if this was ever planned (and I still think it was at some point), the dynamic dispatch on protocol extensions probably killed it off.

Beta 4 Update:

Xcode 7b4 added doc comment support for Throws:, which “should be used to document what errors can be thrown and why”. I guess this at least provides some mechanism to communicate errors to API consumers. Who needs a type system when you have documentation!

Another update:

After spending some time hoping for automatic ErrorType inference, and working out what the limitations would be of that model, I’ve changed my mind - this is what I hope Apple implements instead. Essentially:

// allow us to do this: func myFunction() throws -> Int // or this: func myFunction() throws CustomError -> Int // but not this: func myFunction() throws CustomErrorOne, CustomErrorTwo -> Int 

Yet Another Update

Apple’s error handling rationale is now available here. There have also been some interesting discussions on the swift-evolution mailing list. Essentially, John McCall is opposed to typed errors because he believes most libraries will end up including a generic error case anyway, and that typed errors are unlikely to add much to the code apart from boilerplate (he used the term 'aspirational bluff'). Chris Lattner said he’s open to typed errors in Swift 3 if it can work with the resilience model.

Swift is worry that your case statement is not covering all cases, to fix it you need to create a default case:

do { let sandwich = try makeMeSandwich(kitchen) print("i eat it \(sandwich)") } catch SandwichError.NotMe { print("Not me error") } catch SandwichError.DoItYourself { print("do it error") } catch Default { print("Another Error") } 

I was also disappointed by the lack of type a function can throw, but I get it now thanks to @rickster and I'll summarize it like this: let's say we could specify the type a function throws, we would have something like this:

enum MyError: ErrorType { case ErrorA, ErrorB } func myFunctionThatThrows() throws MyError { ...throw .ErrorA...throw .ErrorB... } do { try myFunctionThatThrows() } case .ErrorA { ... } case .ErrorB { ... } 

The problem is that even if we don't change anything in myFunctionThatThrows, if we just add an error case to MyError:

enum MyError: ErrorType { case ErrorA, ErrorB, ErrorC } 

we are screwed because our do/try/catch is no longer exhaustive, as well as any other place where we called functions that throw MyError

enum NumberError: Error { case NegativeNumber(number: Int) case ZeroNumber case OddNumber(number: Int) } extension NumberError: CustomStringConvertible { var description: String { switch self { case .NegativeNumber(let number): return "Negative number \(number) is Passed." case .OddNumber(let number): return "Odd number \(number) is Passed." case .ZeroNumber: return "Zero is Passed." } } } func validateEvenNumber(_ number: Int) throws ->Int { if number == 0 { throw NumberError.ZeroNumber } else if number < 0 { throw NumberError.NegativeNumber(number: number) } else if number % 2 == 1 { throw NumberError.OddNumber(number: number) } return number } 

Now Validate Number :

 do { let number = try validateEvenNumber(0) print("Valid Even Number: \(number)") } catch let error as NumberError { print(error.description) } 

💡 That is because you didn't specify the throwing error type.

✅ You should define the type of catching error, then switch on the type to make the compiler understand you, like:

do { let sandwich = try makeMeSandwich(names: kitchen) } catch let error as SandwichError { // 👈 Get only the specific typed error switch error { case .NotMe: // Do something case .DoItYourself: // Do something } } 

This way, you are technically ignoring other errors but you can catch them too:

do { let sandwich = try makeMeSandwich(names: kitchen) } catch let error as SandwichError { ... } catch { // Any other error will be matched by this block } 

Upcoming Typed Throws feature in Swift

⚠️ Note that although the next section is merged in Swift's main branch on GitHub, it is still behind the experimental feature flag TypedThrows (upcoming FullTypedThrows). So it is NOT available by default (yet)!

Soon you can specify which error type will be thrown by the function in the first place like:

func makeSandwich() throws(SandwichError) -> String { ... } 

and catch it later like:

do throws(SandwichError) { try makeSandwich() } 

🌐 Here is full detailed information about Typed Throws in Swift.

Error can be handle using switch case in catch

func checkAge(age:Int) throws { guard !(age>0 && age < 18) else{ throw Adult.child } guard !(age >= 60) else{ throw Adult.old } guard (age>0) else{ throw Adult.notExist } } do{ try checkAge(age:0) } catch let error { switch error{ case Adult.child : print("child") case Adult.old : print("old") case Adult.notExist : print("not Exist") default: print("default") } } enum Adult:Error { case child case old case notExist } 

Create enum like this:

//Error Handling in swift enum spendingError : Error{ case minus case limit } 

Create method like:

 func calculateSpending(morningSpending:Double,eveningSpending:Double) throws ->Double{ if morningSpending < 0 || eveningSpending < 0{ throw spendingError.minus } if (morningSpending + eveningSpending) > 100{ throw spendingError.limit } return morningSpending + eveningSpending } 

Now check error is there or not and handle it:

do{ try calculateSpending(morningSpending: 60, eveningSpending: 50) } catch spendingError.minus{ print("This is not possible...") } catch spendingError.limit{ print("Limit reached...") }