Bỏ qua (nghiêm trọng) các lỗi để giữ cho chương trình còn sống?

Question

Một trong những điều chính tôi muốn đạt được trong ngôn ngữ lập trình thử nghiệm của mình là: Khi xảy ra lỗi (Cú pháp, Tên, Loại, v.v.), hãy giữ cho chương trình đang chạy, bất kể nó nghiêm trọng đến mức nào. Tôi biết rằng điều này có thể rất tệ, nhưng tôi chỉ muốn một cái gì đó không tự giết chết mọi lỗi - Tôi thấy điều thú vị xảy ra khi một lỗi nghiêm trọng xảy ra nhưng chương trình vẫn tiếp tục.

• Mô hình "này" có tên không? Ý tôi là mong đợi cho
• Làm thế nào để thực hiện điều này?
• Có các chương trình đang sử dụng ở ngoài mà chỉ cần thực hiện theo: "Xin chào, đây là lỗi nghiêm trọng, bất ngờ - nhưng bạn biết không? Tôi không quan tâm!"?

Answer 1

Về cách đặt tên, bạn có thể nói ngôn ngữ thể hiện "đầu óc heo".

Việc bẻ khóa thường được ưu tiên vì chương trình không được trả về kết quả không thể đoán trước và không thể lặp lại. Không có kết quả nào nói chung tốt hơn một cái không đáng tin cậy, đặc biệt nếu bạn đang làm một việc kinh doanh quan trọng. Ví dụ, tốt hơn là lệnh của khách hàng trên Amazon không được xử lý (họ luôn có thể gửi lại nó) hơn là để khách hàng được phân phối một sản phẩm ngẫu nhiên. Một số lỗi thực sự không thể khôi phục được, ví dụ nếu con trỏ lệnh bị hỏng.

Bạn có thể triển khai bahaviour tương tự bằng hầu hết các ngôn ngữ hiện đại với tất cả các trình xử lý ngoại lệ.

Answer 2

Tôi không biết về tên.

Làm thế nào xấu? Tôi không biết; Những gì bạn đang sử dụng nó cho? Thông thường, tốt hơn là có một vụ tai nạn hơn là một lỗi im lặng. Sự cố là hiển nhiên, và thường có thể được sửa chữa, nhưng các lỗi thầm lặng có thể không được chú ý, và do đó, việc họ sửa lỗi là không quan trọng.

Có những trường hợp trong đó điều này có thể là điều đúng để thực hiện. Tôi đã đọc một máy tính chữa cháy của Hải quân với "thanh chiến đấu" đã tắt các cơ sở ngoại lệ, với điều kiện là nó chạy nó có thể đang cung cấp thông tin tốt, trong khi nếu nó không chạy thì bạn biết rất rõ không phải vậy. Trong trận chiến, nó thường xuyên là trường hợp mà không làm gì là xấu, ngay cả khi bạn không thể làm một cái gì đó đặc biệt hữu ích.

Answer 3

Để chương trình của bạn tiếp tục, bạn phải có trạng thái cơ bản mà bạn biết là tốt và sau đó mỗi yêu cầu được xử lý độc lập. Ví dụ:

• Ứng dụng khách/máy chủ. Các yêu cầu mới đến máy chủ được xử lý độc lập và nếu một yêu cầu không thành công, máy chủ sẽ bắt được và giả sử nó không xảy ra hoặc cho phép khách hàng biết rằng nó không thành công.
• Đơn đăng ký địa phương. Có một số hình thức cơ sở, và tất cả mọi thứ người dùng cố gắng làm là instantiated từ đó. Nếu một quá trình thất bại thảm họa, thể hiện của quá trình này (có thể là một hình thức MDI) bị giết, và người dùng còn lại với mẫu ứng dụng shell ban đầu của họ, miễn phí để thử lại hoặc làm một cái gì đó khác.

Điều lớn nhất phải cẩn thận của nếu bạn đang làm điều này là ứng dụng của bạn phải có một số lõi tối giản đó là lỗi-miễn phí, và sẽ xử lý bất kỳ trường hợp ngoại lệ ngoài ý muốn (không phải là một nhiệm vụ dễ dàng). Chưa kể đến việc nuốt các ngoại lệ không mong muốn có thể làm cho việc gỡ rối/gỡ lỗi khốn khổ, lõi không thể hủy hoại không thể thất bại, nếu không toàn bộ ứng dụng sẽ thất bại.

Answer 4

Tôi đã sử dụng phương pháp xử lý lỗi 'cấu trúc liên kết quân sự'.

Lỗi phải được phân loại theo mức độ nghiêm trọng, sau đó được xử lý hoặc chuyển lên cấp trên để giải quyết.

Riêng tư được yêu cầu dọn sạch mặt đất diễu hành bằng bàn chải đánh răng. Anh ta hết xà phòng. Đó là một vấn đề anh ta nên tìm ra chính mình và không làm phiền cấp trên của mình.

Nếu mặt đất diễu hành có trung đội lính địch hạ cánh, đó có thể là điều anh ta nên nói với cấp trên của mình.

Hãy ghi nhớ tôi trong phần 'đánh dấu' của cuốn sách khi bạn giàu có và nổi tiếng.

Answer 5

Giả sử bạn có thể xác định rằng tất cả các lỗi của loại X là các nút hiển thị và tất cả các lỗi thuộc loại Y thì không. Tôi nghĩ rằng điều này nghe có vẻ tốt trên bề mặt nhưng ma quỷ là trong các chi tiết. Trong thực tế, tôi không nghĩ rằng bạn có thể nghĩ ra một lỗi duy nhất mà luôn luôn là lành tính.

Bạn đề cập đến "Cú pháp, Tên, Loại". Nếu bạn biết các lỗi cú pháp phổ biến có thể cố định khách quan mà không gây ra vấn đề, hãy xây dựng chúng vào spec và để cho trình biên dịch xử lý chúng (tại thời điểm đó chúng sẽ không còn là các lỗi cú pháp). Tôi không biết lỗi "Tên" tầm thường là gì. Tránh lỗi loại là một vấn đề của việc có một hệ thống gõ năng động. Một lần nữa, đây là một phần của spec, không xử lý lỗi.

Điều tôi đang đọc là bạn muốn có một thông số cụ thể, một trình biên dịch linh hoạt cho phép viết cú pháp theo nhiều cách khác nhau và một hệ thống gõ động. Điều này thật tuyệt và tôi chúc bạn may mắn nhất. Nhưng đừng nhầm lẫn điều này với việc giải thích ý định của người lập trình và nghĩ rằng bạn có thể nói một lỗi ok từ một lỗi bất lợi.

Answer 6

Dường như với tôi rằng bạn đang nói về sự khác biệt giữa độ chính xác và độ mạnh. Một chương trình rất mạnh mẽ tiếp tục chạy không có vấn đề gì. Một chương trình có độ chính xác cao chỉ cho ra các kết quả chính xác. Hai phẩm chất này thường phản đối hoàn toàn và phải cân bằng với nhau. Không có cách chung để quyết định sự cân bằng giữa hai người. Nó phụ thuộc vào mục đích của chương trình. Vì vậy, thực sự không có cách nào để một trình biên dịch thông minh quyết định nên ưu tiên nó.

Lập trình cho sự vững mạnh không nhất thiết là một điều xấu. Trình điều khiển thiết bị, ví dụ, có xu hướng mạnh mẽ (ít nhất là những trình điều khiển tốt). Nói chung, nó không phải là ok cho một trình điều khiển thiết bị để thổi lên khi đối mặt với các lỗi bất ngờ vì điều này có thể mất toàn bộ hệ thống. Trình điều khiển thiết bị thường giải thích các lỗi "gây tử vong" trong cách bạn mô tả "Tôi không quan tâm". Ví dụ, nếu phần cứng gửi dữ liệu bị hỏng, nó thường đủ để loại bỏ nó và đợi một mẫu mới.

Answer 7

Phương pháp tiếp cận Erlang có vẻ khá cân bằng. Nếu một quá trình thất bại, nó sẽ không (lý tưởng) ảnh hưởng đến những người khác.