在Swift验证场景及其他场景中使用throw的原因探究

这不是单纯的编码风格偏好，throw在验证场景下确实有不少实际优势，尤其在复杂业务逻辑里会更明显，下面结合你的用户名密码验证例子拆解：

• 语义更清晰，明确区分"正常结果"和"错误"
  你用枚举返回的方式里，passed是验证通过的正常结果，而tooshort、nonumbers是错误情况，但函数返回值把这两类混在了一起。调用者必须手动判断返回值是不是passed才能确定验证成功，逻辑上很容易混淆。
  用throw的话，函数的返回值可以专注于"验证通过时的有效信息"（比如直接返回Void，或者返回处理后的用户数据），错误情况通过抛出异常明确区分。调用者用do-catch结构天然就能把成功逻辑和错误处理分开，代码可读性更高。

• 支持携带更丰富的错误细节
  你的枚举只能返回预定义的几种错误类型，如果要给错误加额外信息（比如密码长度不够时，告诉用户需要至少4位），枚举就很难扩展。而用遵循Error协议的错误类型，可以关联关联值：

  enum CredentialError: Error {
      case tooShort(minLength: Int)
      case noNumbers
      case invalidUsername
  }
  

  抛出错误时能携带具体参数，处理错误时可以根据这些信息给用户更精准的提示。

• 适配Swift语言级别的错误处理机制
  Swift的throw是原生错误处理方案，能和系统API、第三方库的错误逻辑无缝衔接。比如如果验证之后要调用网络请求（本身可能抛出错误），用throw可以把验证错误和网络错误统一用do-catch处理，不用单独适配两种不同的错误返回方式。

• 降低"遗漏错误判断"的风险
  用枚举返回的话，调用者可能会不小心漏掉某些错误情况的判断（比如只处理了nonumbers，忘了tooshort），直接默认验证通过。而用throw的话，编译器会强制要求你处理可能抛出的错误（除非显式用try!或try?忽略），能减少这类逻辑漏洞。

用throw改写的示例代码 #

enum CredentialError: Error {
    case tooShort(minLength: Int)
    case noNumbers
}

func validateCredentials(username: String, password: String) throws {
    let minRequiredLength = 4
    guard username.count >= minRequiredLength && password.count >= minRequiredLength else {
        throw CredentialError.tooShort(minLength: minRequiredLength)
    }
    guard password.rangeOfCharacter(from: .decimalDigits) != nil else {
        throw CredentialError.noNumbers
    }
}

// 调用示例
do {
    try validateCredentials(username: "jeff", password: "password")
    print("验证通过，可继续后续操作")
} catch CredentialError.tooShort(let minLength) {
    print("用户名或密码长度不够，至少需要\(minLength)位")
} catch CredentialError.noNumbers {
    print("密码必须包含至少一个数字")
} catch {
    print("发生未知错误：\(error)")
}

当然，也不是说枚举返回方式完全没用——如果你的验证逻辑非常简单，错误类型极少，且调用者能清晰处理所有返回值，枚举方式也很简洁。但随着业务复杂度提升，throw的优势会越来越突出。

内容的提问来源于stack exchange，提问作者John