Swift開發之異常處理及斷言(一)

本篇分兩部分:

　　1、錯誤和異常處理

　　2、Swift 中的斷言

1、錯誤和異常處理

在 OC 開發中，我們通常會將 error 置為 nil

NSError *error;
BOOL success = [data writeToFile: path options: options error: &error];
if(error) {
    // 錯誤信息
}

　　在絕大多數情況下，這個方法並不會發生什麼錯誤，所以我們將 error 直接設置為 nil。但是出錯的時候可能就會無從下手進行調試。在 Swift 中引入了異常機制，這讓我們老牌程式員感到異常親切，因為在 java 或 C# 中我們會經常使用。但是與 java 不同的是，Swift 中用的是 do...catch 語法，然後在可能跑出異常的地方來用 try 進行修飾，而 java 中直接將可能拋出異常的代碼塊放到 try...catch 中。swift 相較 java 會更快速的鎖定異常代碼的行數，而 java 可能需要一步步調試才能發現 try...catch 中那句發生了錯誤，但我並不認為這是個優點，如果 Swift 中多處都會拋出同樣的異常，每句都去修飾的話會導致代碼異常臃腫。

enum LoginError: ErrorType {
    case UserNotFound, UserPasswordNotMatch
}
func login(user: String, password: String) throws {
    if 1 < 2 {
        throw LoginError.UserNotFound
    }
    if 2 > 1 {
        throw LoginError.UserPasswordNotMatch
    }
    print("Login successfully.")
}

do {
    try login("onevcat", password: "123")
} catch LoginError.UserNotFound {
    print("UserNotFound")
} catch LoginError.UserPasswordNotMatch {
    print("UserPasswordNotMatch")
}

2、Swift 中的斷言

　　斷言(assertion)在 Cocoa 開發里一般用來在檢查輸入參數是否滿足一定條件，並對其進行“論斷”，用於提高開發人員之間的溝通效率。

 在判斷某些輸入參數是否滿足條件時，我們程式員通常用 if 這樣的條件控制來檢測，如果遇到無法繼續的情況就提前返回或跑出錯誤。但是這樣導致了運行時的額外開銷，對於像判斷輸入參數是否滿足條件這樣的情景，我們用斷言處理將會更好。

 swift 中為我們提供的斷言方法:

func assert(@autoclosure condition: () -> Bool,
 @autoclosure _ message: () -> String = default,
 file:StaticString = default,
 line: UInt = default)

舉一個簡單的例子，比如我們的年齡不能小於0歲：

func convertAge(age: Int) -> Int {
    assert(age < 0, "輸入的年齡不能小於0歲")
    return 0
}

let xiaoMingAge = convertAge(-10)

// 運行時錯誤:
// assertion failed:
// 輸入的年齡不能小於0歲

斷言最最基本的作用:

　　在遇到無法處理的輸入時，運行會產生錯誤並拋出我們預設的信息來提醒調用這段代碼的工程師。

斷言的特點:

　　與我們自定義的 NSLog 類似，它是一個開發時的特性，只有在 Debug 編譯的時候有效，而在運行時是不被編譯執行的，因此並不會消耗運行時的性能。這些特點使得斷言稱為面向程式員在調試開發階段非常適合的調試判斷，而在代碼發佈時，我們也不需要刻意去把這些斷言手動清除。

　　如果我們想要在 Debug 模式下強制禁用斷言，在對應的 target 的 Build Setting 中，我們在 Swift Compiler - Custom Flags 中的 Other Swift Flags 中添加 -assert-config Release 來強制禁用斷言，或者 -assert-config Debug 來強制啟用斷言。(不建議這麼做)

註:OC 中的斷言函數 NSAssert 在 Swift 中已被移除。