是否需为每个handle_call函数添加try catch？为何多数未使用？

在Erlang/OTP生态里，不为handle_call添加try/catch是遵循设计哲学与工程实践的选择，核心考量因素如下：

• OTP崩溃优先的设计哲学：Erlang的核心思想是"让错误进程崩溃，由监督树恢复"。监督树会按照预设策略重启崩溃的进程，确保系统回到一致的初始状态。如果在handle_call里用try/catch掩盖错误，可能导致进程处于不一致的状态，反而引发更隐蔽的连锁问题，比直接崩溃更难处理。

• 错误定位的有效性：滥用try/catch会吞掉错误栈信息，反而阻碍问题排查。进程崩溃时生成的crash dump、错误日志（可通过配置日志级别过滤冗余重启信息）能直接定位到错误的代码行和调用栈，而被捕获的错误可能变成隐性bug，长期潜伏在系统中。

• 代码简洁性与维护性：对于逻辑简单、依赖稳定组件的handle_call（比如示例中的队列操作），添加try/catch纯属冗余。示例里调用的:queue模块是Erlang标准库组件，经过大量生产验证，只要状态维护合法，几乎不会抛出异常。额外的异常捕获会增加代码复杂度，降低可读性。

• 区分预期与意外错误：预期的错误（比如参数非法、资源不足）应该通过返回{:error, reason}的显式方式处理，而意外错误（比如逻辑bug、依赖组件崩溃）属于不可预见的问题，让进程崩溃是更安全的选择——避免错误状态扩散，同时触发监督树的恢复机制。

结合你给出的Nx项目stream.ex代码来看：

@impl true
def handle_call(:recv, from, {output, waiting, acc, fun}) do
  case :queue.out(output) do
    {:empty, output} ->
      {:noreply, {output, :queue.in(from, waiting), acc, fun}}

    {{:value, data}, output} ->
      {:reply, {:ok, data}, {output, waiting, acc, fun}}
  end
end

@impl true
def handle_call(:done, _from, {output, waiting, acc, fun}) do
  if :queue.is_empty(output) do
    for from <- :queue.to_list(waiting) do
      GenServer.reply(from, :done)
    end

    {:stop, :normal, {:ok, acc}, {output, waiting, acc, fun}}
  else
    {:reply, :recv_pending, {output, waiting, acc, fun}}
  end
end

这段代码的逻辑围绕:queue的基础操作展开，所有调用的函数都是纯函数且边界清晰，GenServer的状态也严格维护队列的合法性，不存在会触发异常的风险场景，因此完全不需要添加try/catch。

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