Erlang 错误处理哲学 - 案例与抛出

Question

我正在用 Erlang 编写一个 REST 服务，需要先验证接收到的数据，然后再将其传递给其他内部函数进行进一步处理；为了做到这一点，我目前正在使用这样的嵌套case 表达式：

case all_args_defined(Args) of
    true ->
        ActionSuccess = action(Args),

        case ActionSuccess of
            {ok, _} -> ...;
            {fail, reason} -> {fail, reason}
        end,
    _ ->
        {fail, "args not defined"}
end,
...

我意识到这有点难看，但这样我可以提供详细的错误消息。此外，我不认为通常的 让它崩溃 理念在这里适用 - 我不希望我的 REST 服务在每次有人向它抛出无效参数时崩溃并重新启动。

但是，我正在考虑放弃所有 cases，转而使用保护伞 try/catch 阻止捕获任何 badmatch 错误 - 这可行吗？

fun() ->
    true = all_args_defined(Args),
    {ok, _} = action(Args).

%% somewhere else
catch fun().

Answer 1

由于您想要实现的是错误报告，因此您应该围绕执行操作和报告结果来构建事情。也许是这样的：

  execute(Action, Args) ->
    try
      check_args(Args),
      Result = action(Action, Args),
      send_result(Result)
    catch
      throw:{fail, Reason} ->
        report_error(Reason);
      ExceptionClass:Term ->
        %% catch-all for all other unexpected exceptions
        Trace = erlang:get_stacktrace(),
        report_error({crash, ExceptionClass, Term, Trace})
    end.

  %% all of these throw {fail, Reason} if they detect something fishy
  %% and otherwise they return some value as result (or just crash)
  action(foo, [X1, X2]) -> ...;
  action(foo, Args) -> throw({fail, {bad_arity, foo, 2, Args}});
  action(...) -> ...

  %% this handles the formatting of all possible errors 
  report_error({bad_arity, Action, Arity, Args}) ->
    send_error(io_lib:format("wrong number of arguments for ~w: "
                             "expected ~w, but got ~w",
                             [Action, Arity, length(Args)]));
  report_error(...) -> ...;
  report_error({crash, Class, Term, Trace}) ->
    send_error(io_lib:format("internal error: "
                             "~w:~w~nstacktrace:~n~p~n",
                             [Class, Term, Trace])).

Answer 2

我在开发创建用户的应用程序时遇到了这个问题。

我首先提出了这样的解决方案：

insert() ->
    try
        check_1(), % the check functions throw an exception on error.
        check_2(),
        check_3(),
        do_insert()
    catch
        throw:Error1 ->
            handle_error_1();
        throw:Error2 ->
            handle_error_2();
        _:Error ->
            internal_error()
    end.

这个解决方案的问题是你丢失了 try...catch 块的堆栈跟踪。 取而代之的是，一个更好的解决方案是：

insert() ->
    case catch execute() of
        ok -> all_ok;
        {FuncName, Error} ->
            handle_error(FuncName, Error);
        {'EXIT', Error} ->
            internal_error(Error)
    end.

execute() ->
    check_1(), % the check functions throw an exception on error.
    check_2(),
    check_3(),
    do_insert().

这样您就可以在 Error 上获得完整的错误堆栈。

Answer 3

我在编写自己的 REST 服务时遇到了完全相同的问题。

让我们从哲学开始：

我喜欢把我的应用程序想象成一个盒子。盒子里面是我制造的所有部件，可以直接控制。如果这里有问题，那是我的错，它应该崩溃，我应该在错误日志中阅读它。盒子的边缘是与外界的所有连接点——这些都是不可信的。我避免在内部部分进行异常处理，并根据需要将其用于外部边缘。

在我参与过的类似项目中：

我通常会对用户输入进行十几个检查。如果某些东西看起来很糟糕，我会记录它并向用户返回错误。拥有堆栈跟踪对我来说并不是特别有意义 - 如果用户忘记了一个参数，那么我的代码中就没有任何东西可以查找和修复。我宁愿看到这样的文本日志：“在 17:35，用户 X 访问了路径 Y，但缺少参数 Z”。

我将检查组织成返回 ok 或 {error, string()} 的函数。主函数只是迭代检查并返回ok，如果它们都通过，否则它返回第一个错误，然后记录。在我的检查函数中，我根据需要使用异常处理，因为我不可能考虑到用户可能搞砸的所有方式。

按照我的同事的建议，您也可以让每个检查都抛出异常，而不是使用元组。

至于您的实现，如果您只有一次检查，我认为您使用单个异常处理程序的想法是一个很好的想法。如果您最终需要更多检查，您可能希望实现我所描述的内容，以便您可以进行更具体的日志记录。