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キャッチよりも、この真のより効率的ですか？効率が重要なシステム、すなわちスタックトレースを構築することおよび/またはハッピーパスよりも多くの処理を必要とするクラッシュは、可能な限り効率的に処理する必要があるシステムにおいて、このシナリオをどのように処理するのが最適か。

私はちょうどerlangを学んでいるので、おそらく答えは私の顔を見ている。

Answer 1

いいえ、それは逆です：catchは常にスタックトレースを作成するので避けてください。 try + catchの場合は、erlang:get_stacktrace()でスタックトレースを作成するだけです。

リチャード・カールソン（Richard Carlsson）が2013年11月5日にerlang-questionsに投稿した全文はHeads-up: The cost of get_stacktrace()を参照してください。

：私はいくつかの部品引用してみましょう（エグゼクティブサマリー：例外安いのが、のerlang：get_stacktrace（）高価なの一種 ;また、 'キャッチExprに' を避ける。）

多くの状況でget_stacktrace（）を呼び出すことはもちろん有効です。 プロセスがあきらめたり、ログにクラッシュしたり、まれにしか起こらないものがあり、 スタックトレース情報が便利ですが、 が頻繁に使用される可能性のあるライブラリ関数ループで。

最後に、これは非常にも '式のキャッチを試みる...' 末端に 'キャッチExprに' の古い発生を書き換えるための別の理由[...]