performance - 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.

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

我只是在学习erlang，所以也许答案就在盯着我。

Answer 1

不，这是另一回事:避免使用catch，因为它始终会生成堆栈跟踪。 try + catch仅在使用erlang:get_stacktrace()要求时才构建堆栈跟踪。

有关完整故事，请参阅Richardt.Carlsson于2013-11-05发表到erlang-questions上的Heads-up: The cost of get_stacktrace()。让我列举几个部分:

(Executive summary: exceptions cheap, but erlang:get_stacktrace() kind of expensive; also, avoid 'catch Expr'.)

It's of course still valid to call get_stacktrace() in many situations, e.g. when the process is on its way to give up, or to write the crash information to a log, or for something that only happens rarely and the stack trace information is useful - but never in a library function that might be used heavily in a loop.

Finally, this is also another reason to rewrite old occurrences of 'catch Expr' into 'try Expr catch ... end' [...]