Biểu thức 'bắt' của Erlang so với try/catch về mặt hiệu quả

Question

Một câu hỏi tương tự đã được hỏi về điều này nhưng không được hỏi chính xác trong cùng một cụm từ.

Tôi đang cố gắng giải mã một cách an toàn các tệp nhị phân base64, trong ngữ cảnh có thể đầu vào sẽ không phải là mã nhị phân hoặc thậm chí là mã hóa base64.

Erlang nói hãy để nó sụp đổ và xử lý - nếu tôi làm như vậy, cách hiệu quả nhất là gì. Hiệu quả là khá quan trọng trong hệ thống này.

Tôi biết để tránh thử/nắm bắt, vì nó xây dựng một dấu vết ngăn xếp đầy đủ - tuy nhiên, là từ khóa bắt hợp lý cho bối cảnh này? Và là từ khóa bắt nhanh hơn/hiệu quả hơn?

Trong một chức năng như

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

Đây có phải là thực sự hiệu quả hơn một catch? Cách tốt nhất để xử lý kịch bản này trong một hệ thống nơi hiệu quả là quan trọng, tức là các sự cố liên quan đến việc tạo dấu vết ngăn xếp và/hoặc yêu cầu xử lý nhiều hơn đường dẫn hạnh phúc cần được xử lý hiệu quả nhất có thể.

Tôi chỉ đang học tập, vì vậy có thể câu trả lời đang nhìn chằm chằm vào mặt tôi.

Answer 1

Không, đó là cách khác xung quanh: tránh catch vì nó luôn tạo dấu vết ngăn xếp. try + catch chỉ tạo theo dõi ngăn xếp nếu bạn yêu cầu bằng erlang:get_stacktrace().

Xem Heads-up: The cost of get_stacktrace(), được đăng lên câu hỏi xóa bởi Richard Carlsson vào ngày 2013-11-05, cho toàn bộ câu chuyện. Hãy để tôi trích dẫn một vài bộ phận:

(Tóm tắt: trường hợp ngoại lệ giá rẻ, nhưng erlang: get_stacktrace() loại đắt tiền; cũng có, tránh 'bắt expr'.)

Tất nhiên vẫn hợp lệ để gọi get_stacktrace() trong nhiều trường hợp, ví dụ: khi quá trình đang trên đường từ bỏ hoặc viết thông tin về sự cố vào nhật ký hoặc cho một điều hiếm khi xảy ra và thông tin theo dõi ngăn xếp hữu ích - nhưng không bao giờ có chức năng thư viện trong một vòng lặp.

Cuối cùng, đây cũng là một lý do khác để viết lại lần xuất hiện cũ của 'bắt expr' vào 'thử expr bắt ... cuối' [...]