Swift do-try-catch構文

Swift 2の新しいエラー処理を理解するために試してみます。これが私がしたことです：最初にエラー列挙型を宣言しました：

enum SandwichError: ErrorType {
    case NotMe
    case DoItYourself
}

そして、エラーをスローするメソッドを宣言しました（例外ではなく、エラーです）。ここにその方法があります：

func makeMeSandwich(names: [String: String]) throws -> String {
    guard let sandwich = names["sandwich"] else {
        throw SandwichError.NotMe
    }

    return sandwich
}

問題は呼び出し側からです。このメソッドを呼び出すコードは次のとおりです。

let kitchen = ["sandwich": "ready", "breakfeast": "not ready"]

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")
}

do行コンパイラの後は言うErrors thrown from here are not handled because the enclosing catch is not exhaustive。しかし、私の意見では、SandwichError列挙型の場合は2つしかないため、それは網羅的です。

通常のswitchステートメントの場合、swiftは、すべてのケースが処理されたときに網羅的であることを理解できます。

Swift 2のエラー処理モデルには、網羅性と回復力という2つの重要なポイントがあります。まとめると、それらは、スローできることがわかっているエラーだけでなく、考えられるすべてのエラーをキャッチする必要のあるdo/ catchステートメントに要約されます。

関数がスローできるエラーのタイプを宣言するのではなく、関数がスローするかどうかのみを宣言することに注意してください。これはゼロから1の無限大の問題です。誰かが他の人（将来の自分を含む）が使用する関数を定義するときに、関数のすべてのクライアントを、実装のすべての変更に適応させる必要はありません。スローできるエラーを含む関数。あなたはあなたの関数を呼び出すコードがそのような変化に対して回復力があることを望みます。

関数は、どのような種類のエラーをスローするか（または将来的にスローする可能性がある）とcatchは言えないため、エラーをキャッチするブロックは、どのタイプのエラーをスローするかを認識していません。そのため、知っているエラータイプを処理することに加えて、普遍的なcatchステートメントで使用していないエラータイプを処理する必要があります。これにより、将来スローするエラーのセットが関数で変更された場合でも、呼び出し元はそのエラータイプをキャッチできます。エラー。

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 let error {
    print(error.localizedDescription)
}

しかし、それだけではありません。この回復力のアイデアについてもう少し考えてみてください。サンドイッチを設計する方法では、エラーを使用するすべての場所でエラーを説明する必要があります。つまり、エラーケースのセットを変更するたびに、それらを使用するすべての場所を変更する必要があります。

独自のエラータイプを定義する背後にある考え方は、そのようなことを集中できるようにすることです。descriptionエラーのメソッドを定義できます：

extension SandwichError: CustomStringConvertible {
    var description: String {
        switch self {
            case NotMe: return "Not me error"
            case DoItYourself: return "Try sudo"
        }
    }
}

そして、エラー処理コードは、エラータイプにそれ自体を説明するように要求できます。これで、エラーを処理するすべての場所で同じコードを使用できるようになり、将来起こり得るエラーケースも処理できるようになります。

do {
    let sandwich = try makeMeSandwich(kitchen)
    print("i eat it \(sandwich)")
} catch let error as SandwichError {
    print(error.description)
} catch {
    print("i dunno")
}

これにより、エラータイプ（またはその拡張）がエラーを報告する他の方法をサポートできるようになります。たとえば、UIAlertControlleriOSユーザーにエラーを報告するためのを提示する方法を知っているエラータイプの拡張を使用できます。

これはまだ適切に実装されていないのではないかと思います。スウィフトプログラミングガイドは、間違いなく、コンパイラは「switch文のような」徹底的な試合を推測できることを意味するようです。包括的catchであるために将軍が必要であることについては触れていません。

また、エラーがtryブロックの最後ではなく行にあることに気付くでしょう。つまり、ある時点で、コンパイラーはtry、ブロック内のどのステートメントに未処理の例外タイプがあるかを特定できるようになります。

ただし、ドキュメントは少しあいまいです。「Swiftの新機能」ビデオをざっと見てみましたが、手掛かりが見つかりませんでした。頑張ります。

更新：

ErrorType推論のヒントなしで、ベータ3に達しました。私は今、これが計画されていたなら（そして、私はまだそれがいつかそうだったと思います）、プロトコル拡張の動的ディスパッチがおそらくそれを打ち消しました。

Beta 4アップデート：

Xcode 7b4はにdocコメントのサポートを追加しましたThrows:。これは、「どのエラーがスローされる可能性があるか、およびその理由を文書化するために使用する必要があります」。私は、これは、少なくとも提供して推測するいくつかの APIの消費者にエラーを通信するためのメカニズムを。あなたがドキュメントを持っているときに誰が型システムを必要とするのですか！

別の更新：

自動ErrorType推論を期待し、そのモデルの制限が何かを考え出した後、私は考えを変えました。これがAppleが代わりに実装することを望んでいます。基本的に：

// 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

さらに別のアップデート

Appleのエラー処理の理論的根拠がここにあります。また、swift-evolutionメーリングリストについても興味深い議論が行われています。基本的に、ジョンマッコールは型付きエラーに反対しています。なぜなら、ほとんどのライブラリはいずれにせよ一般的なエラーケースを含むことになると考えており、型付きエラーがボイラープレート以外のコードに多くを追加する可能性は低いからです（彼は「吸引ブラフ」という用語を使用しました）。Chris Lattner氏は、Swift 3がレジリエンスモデルで機能すれば、タイプエラーを受け入れる可能性があると語った。

スウィフトはあなたのケースステートメントがすべてのケースをカバーしていないことを心配しています、それを修正するにはデフォルトのケースを作成する必要があります：

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")
}

また、関数がスローできるタイプがないことにもがっかりしましたが、@ ricksterのおかげでそれがわかりました。次のように要約します。関数がスローするタイプを指定できるとしましょう。次のようになります。

enum MyError: ErrorType { case ErrorA, ErrorB }

func myFunctionThatThrows() throws MyError { ...throw .ErrorA...throw .ErrorB... }

do {
    try myFunctionThatThrows()
}
case .ErrorA { ... }
case .ErrorB { ... }

問題は、myFunctionThatThrowsで何も変更しない場合でも、MyErrorにエラーケースを追加するだけの場合です。

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

do / try / catchが完全ではなくなり、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
}

番号を確認してください：

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

次のように列挙型を作成します。

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

次のようなメソッドを作成します。

 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
}

エラーが存在するかどうかを確認して処理します。

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