Erlang'catch'表达与try/catch在效率方面

Question

有人对此提出了类似的问题,但并未按照相同的条款提出问题.

我试图安全地解码base64二进制文件,在一个上下文中,输入可能不是二进制,甚至是base64编码.

Erlang说让它崩溃并处理它 - 如果我这样做,最有效的方法是什么.效率在这个系统中非常重要.

我知道要避免try/catch,因为它构建了一个完整的堆栈跟踪 - 但是,这个上下文的catch关键字是否合理？catch关键字更快/更有效吗？

在诸如的功能中

safe_decode(Binary) ->
    case catch base64:decode(Binary) of
        <<Result/binary>> -> {ok, Result};
        {'EXIT', _} -> {not_base64, Binary}
    end.

这真的比尝试捕获更有效吗？如何在效率很重要的系统中最好地处理这种情况,即需要尽可能有效地处理涉及构建堆栈跟踪和/或需要比快乐路径更多处理的崩溃.

我只是在学习二郎,所以也许答案就是盯着我.

Answer 1

不,这是另一种方式:避免catch因为它总是构建堆栈跟踪. try+ catch如果您要求,则仅构建堆栈跟踪erlang:get_stacktrace().

请参阅Heads-up:get_stacktrace()的费用,由Richard Carlsson在2013-11-05发布到erlang-questions上,全文.让我举几个部分:

(执行摘要:异常便宜,但是erlang:get_stacktrace()有点昂贵;另外,避免'捕获Expr'.)

在许多情况下调用get_stacktrace()当然仍然有效,例如当进程正在放弃,或者将崩溃信息写入日志时,或者只是很少发生的事情,并且堆栈跟踪信息是有用的 - 但从不在可能在循环中大量使用的库函数中.

最后,这也是将旧的'catch Expr'重写为'try Expr catch ... end'[...]的另一个原因.