Lợi ích của việc có không có ngoại lệ trong thời gian chạy, như các yêu cầu của Elm là gì?

Một số ngôn ngữ tuyên bố "không có ngoại lệ thời gian chạy" là một lợi thế rõ ràng so với các ngôn ngữ khác có chúng.

Tôi bối rối về vấn đề này.

Ngoại lệ thời gian chạy chỉ là một công cụ, theo như tôi biết và khi được sử dụng tốt:

• bạn có thể giao tiếp trạng thái "bẩn" (ném dữ liệu bất ngờ)
• thêm ngăn xếp bạn có thể chỉ ra chuỗi lỗi
• bạn có thể phân biệt giữa sự lộn xộn (ví dụ: trả về một giá trị trống trên đầu vào không hợp lệ) và việc sử dụng không an toàn cần sự chú ý của nhà phát triển (ví dụ: ném ngoại lệ vào đầu vào không hợp lệ)
• bạn có thể thêm chi tiết vào lỗi của mình bằng thông báo ngoại lệ cung cấp thêm chi tiết hữu ích giúp gỡ lỗi (về mặt lý thuyết)

Mặt khác, tôi thấy rất khó để gỡ lỗi một phần mềm "nuốt" ngoại lệ. Ví dụ

try { 
  myFailingCode(); 
} catch {
  // no logs, no crashes, just a dirty state
}

Vì vậy, câu hỏi là: lợi thế lý thuyết, mạnh mẽ của việc "không có ngoại lệ thời gian chạy" là gì?

Thí dụ

https://guide.elm-lang.org/

Không có lỗi thời gian chạy trong thực tế. Không có giá trị. Không xác định không phải là một chức năng.

Các ngoại lệ có ngữ nghĩa cực kỳ hạn chế. Chúng phải được xử lý chính xác nơi chúng bị ném hoặc trong ngăn xếp cuộc gọi trực tiếp lên trên và không có dấu hiệu nào cho người lập trình tại thời điểm biên dịch nếu bạn quên làm như vậy.

Tương phản điều này với Elm khi các lỗi được mã hóa thành Kết quả hoặc Maybes , cả hai đều là giá trị . Điều đó có nghĩa là bạn gặp lỗi trình biên dịch nếu bạn không xử lý lỗi. Bạn có thể lưu trữ chúng trong một biến hoặc thậm chí là một bộ sưu tập để trì hoãn việc xử lý chúng trong một thời gian thuận tiện. Bạn có thể tạo một hàm để xử lý các lỗi theo cách dành riêng cho ứng dụng thay vì lặp lại các khối thử bắt rất giống nhau ở mọi nơi. Bạn có thể xâu chuỗi chúng thành một tính toán chỉ thành công nếu tất cả các phần của nó thành công và chúng không phải bị nhồi nhét vào một khối thử. Bạn không bị giới hạn bởi cú pháp tích hợp.

Điều này không có gì giống như "nuốt ngoại lệ." Nó tạo ra các điều kiện lỗi rõ ràng trong hệ thống loại và cung cấp ngữ nghĩa thay thế linh hoạt hơn nhiều để xử lý chúng.

Hãy xem xét ví dụ sau. Bạn có thể dán nó vào http://elm-lang.org/try nếu bạn muốn thấy nó hoạt động.

import Html exposing (Html, Attribute, beginnerProgram, text, div, input)
import Html.Attributes exposing (..)
import Html.Events exposing (onInput)
import String

main =
  beginnerProgram { model = "", view = view, update = update }

-- UPDATE

type Msg = NewContent String

update (NewContent content) oldContent =
  content

getDefault = Result.withDefault "Please enter an integer" 

double = Result.map (\x -> x*2)

calculate = String.toInt >> double >> Result.map toString >> getDefault

-- VIEW

view content =
  div []
    [ input [ placeholder "Number to double", onInput NewContent, myStyle ] []
    , div [ myStyle ] [ text (calculate content) ]
    ]

myStyle =
  style
    [ ("width", "100%")
    , ("height", "40px")
    , ("padding", "10px 0")
    , ("font-size", "2em")
    , ("text-align", "center")
    ]

Lưu ý String.toInttrong calculatechức năng có khả năng thất bại. Trong Java, điều này có khả năng đưa ra một ngoại lệ thời gian chạy. Khi nó đọc đầu vào của người dùng, nó có cơ hội khá tốt. Thay vào đó, Elm buộc tôi phải giải quyết bằng cách trả lại Result, nhưng chú ý rằng tôi không phải giải quyết ngay. Tôi có thể tăng gấp đôi đầu vào và chuyển đổi nó thành một chuỗi, sau đó kiểm tra đầu vào xấu trong getDefaulthàm. Địa điểm này phù hợp hơn cho việc kiểm tra so với điểm xảy ra lỗi hoặc hướng lên trong ngăn xếp cuộc gọi.

Cách trình biên dịch buộc bàn tay của chúng ta cũng tinh vi hơn nhiều so với các ngoại lệ được kiểm tra của Java. Bạn cần sử dụng một chức năng rất cụ thể như Result.withDefaultđể trích xuất giá trị bạn muốn. Mặc dù về mặt kỹ thuật bạn có thể lạm dụng loại cơ chế đó, không có nhiều điểm. Vì bạn có thể trì hoãn quyết định cho đến khi bạn biết một thông báo lỗi / mặc định tốt để đặt, không có lý do gì để không sử dụng nó.

Để hiểu được tuyên bố này, trước tiên chúng ta phải hiểu hệ thống kiểu tĩnh mua gì cho chúng ta. Về bản chất, những gì một hệ thống kiểu tĩnh mang lại cho chúng ta, là một sự đảm bảo: nếu kiểm tra loại chương trình, một lớp hành vi thời gian chạy nhất định không thể xảy ra.

Nghe có vẻ đáng ngại. Vâng, một trình kiểm tra loại tương tự như trình kiểm tra định lý. (Trên thực tế, theo Curry-Howard-Isomorphism, chúng giống nhau.) Một điều rất đặc biệt về các định lý là khi bạn chứng minh một định lý, bạn chứng minh chính xác những gì định lý nói, không hơn. (Đó là ví dụ, tại sao, khi ai đó nói "Tôi đã chứng minh chương trình này đúng", bạn nên luôn luôn hỏi "vui lòng xác định 'chính xác" ".) Điều tương tự cũng đúng với các hệ thống loại. Khi chúng tôi nói "một chương trình là loại an toàn", điều chúng tôi muốn nói là không có lỗi nào có thể xảy ra. Chúng tôi chỉ có thể nói rằng các lỗi hệ thống loại hứa với chúng tôi sẽ không thể xảy ra.

Vì vậy, các chương trình có thể có vô số hành vi thời gian chạy khác nhau. Trong số đó, vô số những cái là hữu ích, nhưng cũng có vô số cái là "không chính xác" (đối với các định nghĩa khác nhau về "tính chính xác"). Một hệ thống kiểu tĩnh cho phép chúng tôi chứng minh rằng một tập hợp hữu hạn, cố định của vô số những hành vi thời gian chạy không chính xác có thể xảy ra.

Sự khác biệt giữa các hệ thống loại khác nhau về cơ bản là trong đó, bao nhiêu và các hành vi thời gian chạy phức tạp mà chúng có thể chứng minh là không xảy ra. Các hệ thống loại yếu như Java chỉ có thể chứng minh những điều rất cơ bản. Ví dụ, Java có thể chứng minh rằng một phương thức được gõ là trả về Stringkhông thể trả về a List. Nhưng, ví dụ, nó không thể chứng minh rằng phương thức sẽ không trả về. Nó cũng không thể chứng minh rằng phương pháp sẽ không ném ngoại lệ. Và nó không thể chứng minh rằng nó sẽ không trả về sai String  - bất kỳ Stringsẽ thỏa mãn trình kiểm tra loại. (Và, tất nhiên, thậm chí nullsẽ làm hài lòng nó là tốt.) Thậm chí còn có những điều rất đơn giản mà Java không thể chứng minh, đó là lý do chúng tôi có trường hợp ngoại lệ như ArrayStoreException, ClassCastExceptionhoặc tất cả mọi người yêu thích, các NullPointerException.

Các hệ thống loại mạnh hơn như Agda cũng có thể chứng minh những thứ như "sẽ trả về tổng của hai đối số" hoặc "trả về phiên bản đã sắp xếp của danh sách được truyền dưới dạng đối số".

Bây giờ, ý nghĩa của các nhà thiết kế của Elm khi tuyên bố rằng họ không có ngoại lệ về thời gian chạy là hệ thống loại của Elm có thể chứng minh sự vắng mặt của (một phần đáng kể) các hành vi thời gian chạy mà trong các ngôn ngữ khác không thể được chứng minh là không xảy ra và do đó có thể dẫn đến hành vi sai lầm trong thời gian chạy (trong trường hợp tốt nhất có nghĩa là một ngoại lệ, trong trường hợp xấu hơn có nghĩa là một sự cố và trong trường hợp xấu nhất có nghĩa là không có sự cố, không có ngoại lệ và chỉ là kết quả sai lầm âm thầm).

Vì vậy, họ không nói rằng "chúng tôi không thực hiện các ngoại lệ". Họ đang nói rằng "những thứ sẽ là ngoại lệ thời gian chạy trong các ngôn ngữ điển hình mà các lập trình viên điển hình đến với Elm sẽ có kinh nghiệm, bị hệ thống loại bắt gặp". Tất nhiên, ai đó đến từ Idris, Agda, Guru, Epigram, Isabelle / HOL, Coq hoặc các ngôn ngữ tương tự sẽ thấy Elm khá yếu khi so sánh. Tuyên bố này nhắm nhiều hơn vào các lập trình viên Java, C♯, C ++, Objective-C, PHP, ECMAScript, Python, Ruby, Perl, giật.

Elm có thể đảm bảo không có ngoại lệ thời gian chạy vì cùng lý do C có thể đảm bảo không có ngoại lệ thời gian chạy: Ngôn ngữ không hỗ trợ khái niệm ngoại lệ.

Elm có cách báo hiệu các điều kiện lỗi khi chạy, nhưng hệ thống này không phải là ngoại lệ, đó là "Kết quả". Hàm có thể không trả về "Kết quả" chứa giá trị thông thường hoặc lỗi. Elms được gõ mạnh, vì vậy điều này là rõ ràng trong hệ thống loại. Nếu một hàm luôn trả về một số nguyên, nó có kiểu Int. Nhưng nếu nó trả về một số nguyên hoặc không thành công, kiểu trả về là Result Error Int. (Chuỗi là thông báo lỗi.) Điều này buộc bạn phải xử lý rõ ràng cả hai trường hợp tại trang web cuộc gọi.

Đây là một ví dụ từ phần giới thiệu (đơn giản hóa một chút):

view : String -> String 
view userInputAge =
  case String.toInt userInputAge of
    Err msg ->
        text "Not a valid number!"

    Ok age ->
        text "OK!"

Hàm toIntcó thể thất bại nếu đầu vào không thể phân tích cú pháp, vì vậy kiểu trả về của nó là Result String int. Để có được giá trị số nguyên thực tế, bạn phải "giải nén" thông qua khớp mẫu, điều này buộc bạn phải xử lý cả hai trường hợp.

Kết quả và các trường hợp ngoại lệ về cơ bản làm điều tương tự, sự khác biệt quan trọng là "mặc định". Các ngoại lệ sẽ nổi bong bóng và chấm dứt chương trình theo mặc định và bạn phải nắm bắt chúng một cách rõ ràng nếu bạn muốn xử lý chúng. Kết quả là một cách khác - bạn buộc phải xử lý chúng theo mặc định, vì vậy bạn phải vượt qua tất cả chúng để lên đỉnh nếu bạn muốn chúng chấm dứt chương trình. Thật dễ dàng để xem làm thế nào hành vi này có thể dẫn đến mã mạnh mẽ hơn.

Đầu tiên, xin lưu ý rằng ví dụ về các trường hợp ngoại lệ "nuốt" của bạn nói chung là một thực tiễn khủng khiếp và hoàn toàn không liên quan đến việc không có ngoại lệ về thời gian chạy; Khi bạn nghĩ về nó, bạn đã có một lỗi thời gian chạy, nhưng bạn đã chọn để ẩn nó và không làm gì về nó. Điều này thường sẽ dẫn đến các lỗi khó hiểu.

Câu hỏi này có thể được diễn giải theo bất kỳ cách nào, nhưng vì bạn đã đề cập đến Elm trong các bình luận, bối cảnh rõ ràng hơn.

Elm, trong số những thứ khác, là một ngôn ngữ lập trình gõ tĩnh . Một trong những lợi ích của loại hệ thống này là nhiều loại lỗi (mặc dù không phải tất cả) được trình biên dịch bắt gặp, trước khi chương trình thực sự được sử dụng. Một số loại lỗi có thể được mã hóa theo các loại (như Elm Resultvà Task), thay vì bị ném như ngoại lệ. Đây là ý nghĩa của các nhà thiết kế của Elm: nhiều lỗi sẽ bị bắt khi biên dịch thay vì "thời gian chạy" và trình biên dịch sẽ buộc bạn phải xử lý chúng thay vì bỏ qua chúng và hy vọng điều tốt nhất. Rõ ràng tại sao đây là một lợi thế: tốt hơn là lập trình viên nhận thức được vấn đề trước khi người dùng thực hiện.

Lưu ý rằng khi bạn không sử dụng ngoại lệ, lỗi được mã hóa theo những cách khác, ít gây ngạc nhiên hơn. Từ tài liệu của Elm :

Một trong những đảm bảo của Elm là bạn sẽ không thấy lỗi thời gian chạy trong thực tế. NoRedInk đã sử dụng Elm trong sản xuất khoảng một năm nay và họ vẫn chưa có! Giống như tất cả các đảm bảo trong Elm, điều này dẫn đến các lựa chọn thiết kế ngôn ngữ cơ bản. Trong trường hợp này, chúng tôi được giúp đỡ bởi thực tế là Elm coi lỗi là dữ liệu. (Bạn có nhận thấy chúng tôi làm cho mọi thứ dữ liệu ở đây không?)

Các nhà thiết kế Elm hơi táo bạo khi tuyên bố "không có ngoại lệ về thời gian chạy" , mặc dù họ đủ điều kiện với "trong thực tế". Điều họ có thể có nghĩa là "ít lỗi hơn bất ngờ so với khi bạn đang mã hóa trong javascript".

Elm tuyên bố:

Không có lỗi thời gian chạy trong thực tế. Không có giá trị. Không xác định không phải là một chức năng.

Nhưng bạn hỏi về ngoại lệ thời gian chạy . Có một sự khác biệt.

Trong Elm, không có gì trả về một kết quả bất ngờ. Bạn KHÔNG thể viết chương trình hợp lệ trong Elm tạo ra lỗi thời gian chạy. Vì vậy, bạn không cần ngoại lệ.

Vì vậy, câu hỏi nên là:

Lợi ích của việc "không có lỗi thời gian chạy" là gì?

Nếu bạn có thể viết mã không bao giờ có lỗi thời gian chạy, chương trình của bạn sẽ không bao giờ bị sập.