你们喜欢 throw error 吗？

[FaiChou]

平时普通的业务逻辑开发中，越来越不想 throw error 了，而是返回空。

比如 swift 中：

func req() async -> String? {
  if let foo = try? await SomeAsyncThrowsFunc() {
    return foo
  }
  return nil
}

用到的地方:

Task {
  if let val = await req() {
    // get the string value
  } else {
    // somethings up
  }
}

下面是使用 throw 的版本:

func req() async throws -> String {
    if let foo = try await SomeAsyncThrowsFunc() {
        return foo
    }
}

用到的地方:

Task {
  do {
      let val = try await req()
      // get the string value
  } catch {
      // catch the error
  }
}

或者直接将错误转换成 Optional 赋值:
if let val = try? await req() {}

平时的业务逻辑没有写的那么完美，如果是写一个标准的库，定义所有的错误类型，遇到情况不对，throw 相对应的错误。但是到业务逻辑调用，函数包裹的越多，可能在中间一层将错误给抹掉，后面再也拿不到正确的错误值了。

所以要想要规范，必须从头到尾规范起来，中间不能有松懈。但是，要偷懒，真的爽。（也承认自己写的不规范）

[fgwmlhdkkkw]

服务端不一样，有些功能是依赖异常的。比如事务的完全处理。

[zoharSoul]

最外层统一捕获返回给前端/客户端就 ok 了

[TWorldIsNButThis]

我现在倾向于返回 result ，用的地方指定是 throw 还是 null
当然不是 swift

[FaiChou]

@TWorldIsNButThis 对的，Swift 只是个例子，其他语言比如 js 也可以这样做，返回空，用到时候判断是否为空，这样写起来比 try catch 省一些代码量。

[yazinnnn]

你 throw 完了自己处理跟不 throw 有啥区别....

throw 的前提当然是上一层的调用栈有统一的异常管理

[cheng6563]

用 go 吧，没有 throw 功能，每次都是直接返回 err ，你自己判断处理就是了。

[suyuyu]

我还以为你要说 js

[matepi]

throw 真正的意义是消息传递，return null 是函数返回
为啥会对等起来比呢…

[sampeng]

我比较倾向这个懒不能偷。写时一时爽，排查火葬场

[potatowish]

返回空说明是正常的业务逻辑，throw error 是业务流程异常，你为啥会把这俩对等？

[lanlanye]

空值和异常不能对等，这是两种完全不同的东西。

如果单论异常处理的话，有传统的 try...catch...方法，也有 Go 语言那种多返回值的方法。根据我个人的使用经验，前一种就非常好用，问题是可能会忘记处理，后一种的话需要语言支持自动把异常抛回上一层（比如 Rust ），否则代码写起来非常坐牢。

[Masoud2023]

你不好好处理异常，到时候异常就来处理你，到时候调用栈摞的高了，出问题你只能看到一个空返回值的时候你就知道错了。

[Building]

try catch 总感觉像上个世纪的用法
现代用法：Result<Success, Error>

[thetbw]

throw 可以中断后续的代码执行，不然你只能每个地方每个方法调用都是
if result == null
return null //or return error
写一堆判断，就像 go 那种，看着就烦

[StoneHuLu]

你 return null 不抛异常带来的结果就是：菜鸡同事调你方法没判 null ，然后上线之后日志里面只有个 null point exception 。到时候查都不好查，throw exception 的好处是你可以定一下异常信息，日志里起码能看到，能抛异常就抛异常，别把异常当成 null 值处理，万一别人翻不了你源码，直接引用你 dll 文件或者类库，你让调用你的人怎么办，现去翻你文档还是直接找你问为啥？

[nuk]

我不光不 throw ，还要 catch 内部错误不处理，假装一切正常，有问题肯定是别人的问题，我这里都正常。