Erlang 'catch'식 대 효율성의 관점에서 시도/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. 

는 시도 캐치 이상이 진정으로 더 효율적인가요? 효율성이 중요시되는 시스템, 즉 스택 추적을 구축하거나 해피 경로보다 더 많은 처리를 요구하는 충돌이 가능한 한 효율적으로 처리되어야하는 시스템에서이 시나리오를 처리하는 가장 좋은 방법.

나는 방금 erlang을 배우기 때문에, 아마도 그 답은 저를 쳐다보고 있습니다.

Answer 1

아니요, 다른 방법입니다. 항상 스택 추적을 작성하므로 catch을 피하십시오. try + catch은 erlang:get_stacktrace()으로 요청하면 스택 추적 만 작성합니다.

전체 기사는 2013 년 11 월 5 일에 Richard Carlsson이 작성한 erlang-questions에 게시 된 Heads-up: The cost of get_stacktrace()을 참조하십시오.

: 내가 몇 부분 인용하자 (내용 요약 : 예외 싼하지만 얼랑 : get_stacktrace() 고가의 종류 , 또한, '캐치 EXPR'을 피할 수 있습니다.)

많은 상황에서 get_stacktrace()를 호출하는 것은 물론 유효합니다. 예. 프로세스가 포기하고, 로그에 크래시 정보를 기록하거나 드물게 발생하는 경우에만 스택 추적 정보가 유용하지만 라이브러리 기능에서는 결코 이 많이 사용될 수 있습니다 루프. 마지막으로

,이 '... 끝을 EXPR 캐치를 시도'도에 '캐치 EXPR'의 옛 발생을 재 작성하는 또 다른 이유는 [...]