Làm thế nào các lỗi nên được báo cáo trong các thư viện khoa học?

Có nhiều triết lý trong các ngành kỹ thuật phần mềm khác nhau về cách các thư viện nên đối phó với các lỗi hoặc các điều kiện đặc biệt khác. Một vài trong số những cái tôi đã thấy:

1. Trả về mã lỗi với kết quả được trả về bởi một đối số con trỏ. Đây là những gì PETSc làm.
2. Trả về lỗi bằng một giá trị sentinel. Ví dụ, malloc trả về NULL nếu không thể cấp phát bộ nhớ, sqrtsẽ trả về NaN nếu bạn chuyển số âm, v.v ... Cách tiếp cận này được sử dụng trong nhiều hàm libc.
3. Ném ngoại lệ. Được sử dụng trong deal.II, Trilinos, v.v.
4. Trả về một loại biến thể; ví dụ, hàm C ++ trả về một đối tượng kiểu Resultnếu nó chạy chính xác và sử dụng một kiểu Errorđể mô tả cách nó thất bại sẽ trả về std::variant<Error, Result>.
5. Sử dụng khẳng định và sụp đổ. Được sử dụng trong p4est và một số phần của igraph.

Vấn đề với từng phương pháp:

1. Kiểm tra cho mọi lỗi giới thiệu rất nhiều mã bổ sung. Các giá trị mà kết quả sẽ được lưu trữ luôn phải được khai báo trước, đưa ra nhiều biến tạm thời chỉ có thể được sử dụng một lần. Cách tiếp cận này giải thích những gì đã xảy ra lỗi nhưng có thể khó xác định lý do tại sao hoặc, đối với ngăn xếp cuộc gọi sâu, ở đâu.
2. Các trường hợp lỗi là dễ dàng để bỏ qua. Trên hết, nhiều hàm thậm chí không thể có giá trị sentinel có ý nghĩa nếu toàn bộ phạm vi của các loại đầu ra là kết quả chính đáng. Nhiều vấn đề tương tự như # 1.
3. Chỉ có thể có trong C ++, Python, v.v., không có trong C hoặc Fortran. Có thể được bắt chước trong C bằng cách sử dụng phép thuật setjmp / longjmp hoặc libunwind .
4. Chỉ có thể có trong C ++, Rust, OCaml, v.v., không có trong C hoặc Fortran. Có thể được bắt chước trong C bằng cách sử dụng phép thuật vĩ mô.
5. Có thể cho rằng nhiều thông tin nhất. Nhưng nếu bạn áp dụng cách tiếp cận này, giả sử, một thư viện C mà sau đó bạn viết một trình bao bọc Python cho, một lỗi ngớ ngẩn như chuyển một chỉ mục ngoài giới hạn cho một mảng sẽ làm hỏng trình thông dịch Python.

Phần lớn lời khuyên trên internet về xử lý lỗi được viết từ quan điểm của hệ điều hành, phát triển nhúng hoặc ứng dụng web. Sự cố là không thể chấp nhận và bạn phải lo lắng về bảo mật. Các ứng dụng khoa học không có những vấn đề này ở mức độ gần như nhau, nếu có.

Một xem xét khác là những loại lỗi có thể phục hồi hay không. Một thất bại malloc là không thể phục hồi và, trong mọi trường hợp, kẻ giết người hết bộ nhớ hệ điều hành sẽ nhận được nó trước khi bạn làm. Một chỉ mục nằm ngoài giới hạn cho kích thước mảng cũng không thể phục hồi được. Đối với tôi là người dùng, điều tốt nhất mà thư viện có thể làm là gặp sự cố với thông báo lỗi thông tin. Mặt khác, sự thất bại của bộ giải tuyến tính lặp để hội tụ có thể được phục hồi bằng cách sử dụng bộ giải nhân tố trực tiếp.

Làm thế nào các thư viện khoa học báo cáo lỗi và mong đợi chúng sẽ được xử lý? Tất nhiên tôi nhận ra rằng nó phụ thuộc vào ngôn ngữ mà thư viện được triển khai. Nhưng theo như tôi có thể nói, đối với bất kỳ thư viện đủ hữu ích nào, mọi người sẽ muốn gọi nó từ một ngôn ngữ khác ngoài ngôn ngữ mà nó được triển khai.

Bên cạnh đó, tôi nghĩ rằng cách tiếp cận số 5 có thể được cải thiện đáng kể cho thư viện C nếu nó xác định con trỏ hàm xử lý xác nhận toàn cầu là một phần của API công khai. Trình xử lý xác nhận sẽ mặc định báo cáo số tập tin / số dòng và sự cố. Các ràng buộc C ++ cho thư viện này sẽ xác định một trình xử lý xác nhận mới thay vào đó ném một ngoại lệ C ++. Tương tự, các ràng buộc Python sẽ xác định một trình xử lý xác nhận sử dụng API CPython để ném ngoại lệ Python. Nhưng tôi không biết bất kỳ ví dụ nào áp dụng phương pháp này.

Tôi sẽ cung cấp cho bạn quan điểm của tôi, được mã hóa trong dự án deal.II mà bạn tham khảo.

Đầu tiên, có hai loại điều kiện lỗi: Lỗi có thể được phục hồi và lỗi không thể phục hồi.

• Ví dụ, trước đây là nếu một tệp đầu vào không thể đọc được - ví dụ nếu bạn đang đọc thông tin từ một tệp như vậy $HOME/.dealiicó thể tồn tại hoặc không tồn tại. Chức năng đọc chỉ cần quay lại chức năng gọi cho cái sau để biết phải làm gì. Nó cũng có thể là một tài nguyên không có sẵn tại thời điểm này nhưng có thể sẽ trở lại sau một phút (một hệ thống tệp được gắn từ xa).

• Ví dụ, thứ hai là, nếu bạn đang cố gắng thêm một vectơ kích thước 10 vào một vectơ kích thước 20: Hãy thử như bạn có thể, không có gì có thể làm được về điều này - có một lỗi trong mã dẫn đến điểm mà chúng tôi đã cố gắng để làm bổ sung.

Hai điều kiện này nên được xử lý khác nhau, bất kể ngôn ngữ lập trình bạn đang sử dụng là gì:

• Trong trường hợp thứ hai, vì không có sự truy đòi, chấm dứt chương trình. Bạn có thể làm điều đó bằng cách ném một ngoại lệ hoặc trả lại mã lỗi cho người gọi biết rằng không có gì có thể được thực hiện, nhưng bạn cũng có thể hủy bỏ chương trình ngay lập tức vì điều đó giúp lập trình viên dễ dàng gỡ lỗi hơn.

• Trong trường hợp trước đây, một tình huống đặc biệt đã phát sinh có thể được xử lý. Mặc dù C và Fortran không có cách nào để diễn đạt điều này, tất cả các ngôn ngữ hợp lý mà sau này đã kết hợp các cách vào tiêu chuẩn ngôn ngữ để đối phó với các lợi nhuận "đặc biệt" như vậy bằng cách cung cấp, "ngoại lệ". Sử dụng những thứ này - đó là những gì họ đang ở đó; chúng cũng được thiết kế theo cách mà bạn không thể quên bỏ qua chúng (nếu bạn làm thế, ngoại lệ chỉ lan truyền một cấp độ cao hơn).

Nói cách khác, những gì tôi ủng hộ ở đây (và những gì thỏa thuận.II làm) là một hỗn hợp các chiến lược 3 và 5 của bạn, tùy thuộc vào ngữ cảnh. Đúng là 3 không hoạt động với các ngôn ngữ như C hoặc Fortran - trong trường hợp đó, người ta có thể lập luận rằng đó là lý do chính đáng để không sử dụng các ngôn ngữ gây khó khăn để diễn đạt những gì bạn muốn làm.

$x$), nhưng vì người đánh giá cần được gọi nhiều lần nên nó không bị sập mà chỉ ném một ngoại lệ. Trong những trường hợp như vậy, mặc dù việc chuyển qua một giá trị âm không thể phục hồi được, người ta nên ném một ngoại lệ thay vì hủy bỏ chương trình. Tôi đã không đồng ý với lập trường này một vài năm trước đây, nhưng đã thay đổi suy nghĩ của mình sau khi các nguyên tắc phần mềm cộng đồng xSDK mã hóa yêu cầu rằng các chương trình không bao giờ bị sập (hoặc ít nhất nên có cách chuyển từ sự cố sang ngoại lệ - vì vậy hãy giải quyết. Bây giờ tôi có tùy chọn để Assertném ngoại lệ thay vì gọi abort().)