Tại sao không sử dụng từ lỗi thay vì ngoại lệ? [đóng cửa]

Nếu chúng ta coi ngoại lệ là lỗi, tại sao không gọi nó là lỗi ngay từ đầu thay vì ngoại lệ?

Nếu trong mã, nó được gọi là ngoại lệ và ngay khi nó xảy ra, nó được gọi là lỗi. Vậy thì tại sao không gọi nó là một lỗi ở nơi đầu tiên?

Cảm ơn bạn cho bất kỳ câu trả lời hoặc bình luận.

Chà, nó khá đơn giản: không phải tất cả các ngoại lệ đều là lỗi (và tương tự, không phải tất cả các lỗi đều biểu hiện là ngoại lệ).

Ví dụ về một ngoại lệ không phải là lỗi, nếu bạn đang đọc tệp từ ổ USB và ai đó lấy ổ đĩa ra khỏi ổ cắm. Điều đó sẽ đưa ra một ngoại lệ (trong hầu hết các ngôn ngữ hỗ trợ các ngoại lệ, đó là). Nhưng nó không phải là một lỗi trong mã.

Ngược lại, một lỗi có thể tự biểu hiện là lỗi tính toán hoặc một cái gì đó. Bạn vẫn nhận được câu trả lời, đó không phải là câu trả lời đúng.

Phải nói rằng, một ngoại lệ khiến nó có thể đi đến đỉnh của ngăn xếp có khả năng là một lỗi. Trong ví dụ về USB của tôi ở trên, bạn sẽ có thể bắt được ngoại lệ đó và đưa ra một lỗi hay cho người dùng nói rằng "Chúng tôi không thể đọc từ tệp vì nó không còn được kết nối." hoặc một cái gì đó. Nếu bạn chỉ đưa ra một IOExceptionvà một số mã lỗi thú vị, thì đó là một lỗi. Nhưng bản thân ngoại lệ thì không.

Rõ ràng và đơn giản, một ngoại lệ không phải là (luôn luôn) một lỗi!

Một ngoại lệ được ném (hoặc nên là) khi một cái gì đó đặc biệt xảy ra. Nếu có vấn đề với ổ cứng của tôi và một tập tin không thể được ghi, đó không phải là một lỗi. Đó là một thất bại của phần cứng.

Một lỗi nói chung là kết quả của lập trình xấu. Nếu một ứng dụng làm điều gì đó không được mong đợi do lỗi lập trình, thì đó là một lỗi.

Chúng không giống nhau.

Một lỗi là hành vi ngoài ý muốn của một phần mềm: phần mềm không làm những gì nó phải làm. Lỗi có thể sống ở tất cả các cấp độ phát triển phần mềm, từ lỗi chính tả cũ cho đến lỗi logic cho đến thông số chức năng không đầy đủ.

Ngược lại, một ngoại lệ có thể đề cập đến một điều kiện bất thường của chương trình, lệch khỏi hoạt động bình thường hoặc cụ thể hơn là cấu trúc ngôn ngữ được sử dụng để báo hiệu và xử lý các điều kiện đó.

Thực tế là một ngoại lệ xảy ra có thể là dấu hiệu của một lỗi, nhưng thường thì không. Ví dụ: một ứng dụng được cho là tải xuống một tài liệu từ một URL và xử lý nó cục bộ có thể tạo ra một ngoại lệ khi máy chủ từ xa không hoạt động: ứng dụng bị lệch khỏi hoạt động bình thường (nó không thể tải xuống và xử lý tài liệu), nhưng nếu nó xử lý ngoại lệ đúng cách và phục hồi, sau đó không có lỗi.

Ngược lại, sự hiện diện của một lỗi không nhất thiết phải biểu hiện như một ngoại lệ. Một ứng dụng có thể âm thầm loại bỏ dữ liệu bạn nhập thay vì lưu trữ nó trong cơ sở dữ liệu của nó; không có ngoại lệ bị ném, nhưng nó vẫn là một lỗi.

Ngoại lệ và lỗi không liên quan đến tất cả. Chắc chắn, đôi khi bạn ném một ngoại lệ và nó có nghĩa là một lỗi. Nhưng đôi khi nó chỉ có nghĩa là một tình huống đặc biệt, bất thường, không nhất thiết là một lỗi trong chương trình. Đặc biệt là trong một ngôn ngữ hạnh phúc ngoại lệ như Java, nơi mọi hoạt động tiêu chuẩn và con chó của nó ném ra khoảng năm ngoại lệ khác nhau - ví dụ: mở tệp không thành công, đọc tệp thất bại, v.v.

Các ngoại lệ không phải lúc nào cũng liên quan đến lỗi. Hãy nghĩ về nó như một cái gì đó có thể đi sai với những gì bạn đang làm.

Một ví dụ xuất hiện trong tâm trí là InetAddress.getByName () được sử dụng để phân giải một tên miền. Nếu có điều gì đó xảy ra và một UnknownhostException bị ném thì đó không thực sự là vấn đề về mã.

Lỗi phần mềm là thuật ngữ phổ biến được sử dụng để mô tả lỗi, sai sót, lỗi, lỗi hoặc lỗi trong chương trình máy tính hoặc hệ thống tạo ra kết quả không chính xác hoặc không mong muốn hoặc khiến nó hoạt động theo cách không lường trước được. Thậm chí có thể là một lỗi chính tả trên nhãn.

Ngoại lệ khác với lỗi. Mỗi loại ngoại lệ (vi phạm truy cập, tràn ngăn xếp, v.v.) có thể được nâng lên trình gỡ lỗi dưới dạng ngoại lệ "cơ hội thứ nhất" hoặc "cơ hội thứ hai". Theo định nghĩa, các trường hợp ngoại lệ cơ hội đầu tiên là không gây tử vong trừ khi chúng không được xử lý đúng cách với trình xử lý lỗi, tại thời điểm đó chúng được đưa ra lại như một ngoại lệ cơ hội thứ hai (chỉ có trình gỡ lỗi mới có thể xử lý).

Nếu không có trình gỡ lỗi xử lý ngoại lệ cơ hội thứ hai, ứng dụng sẽ bị tắt.

Bạn có thể tự đưa ra một ngoại lệ một cách hợp pháp, bạn hy vọng sẽ không bao giờ đưa ra một lỗi về mục đích.

Tất cả các ngoại lệ không phải là lỗi. Nó có thể là một chủ đề tranh luận rằng tất cả các lỗi là ngoại lệ hay không.

Chúng ta có thể nói ngoại lệ là các sự kiện không phải là một phần của dòng ứng dụng thông thường hoặc dự kiến. Các sự kiện này có thể độc lập với cách mã được viết trong đó lỗi cơ bản là kết quả của mã xấu (như tính toán sai).

Dưới đây là một ví dụ về cách không xử lý một ngoại lệ có thể là một lỗi.

Chúng ta hãy giả sử có một chương trình ghi một số dữ liệu vào một thiết bị lưu trữ ngoài. Trong khi viết thiết bị lưu trữ bên ngoài đã được rút phích cắm, bị hỏng hoặc có thể bị phá hủy (vì lý do từng có). Bây giờ đây là một trường hợp đặc biệt, bây giờ bất kể ngôn ngữ lập trình có hỗ trợ xử lý đặc biệt hay không nếu chương trình gặp sự cố hoặc hoạt động sai do sự kiện này, đó là một lỗi. (Người dùng cuối có thể không biết chuyện gì đã xảy ra. Nó cũng rất khó chịu) . Nhưng nếu chương trình hủy bỏ quá trình một cách duyên dáng, hãy thông báo cho người dùng (nói cách khác là xử lý sự miễn trừ) đây rõ ràng không phải là một lỗi.

Các ngôn ngữ lập trình thử máy móc cung cấp về cơ bản là một công cụ giúp chúng ta dễ dàng xử lý các sự kiện bất ngờ.

Tóm tắt nội dung : Ngoại lệ là bằng chứng về kết quả xấu, lỗi là (một số) nguyên nhân dẫn đến kết quả xấu. Vấn đề (sẽ được giải quyết) không phải là ngoại lệ, vấn đề là nguyên nhân gây ra ngoại lệ.

Resoning: Một lỗi là một khiếm khuyết trong thiết kế hoặc thực hiện một sản phẩm (không giới hạn phần mềm). Ví dụ, không sử dụng rơle được xếp hạng chính xác (thời gian / độ nhạy / độ tin cậy / công suất) do thông số kỹ thuật không chính xác hoặc lỗi xây dựng đơn giản. Một ngoại lệ là độ lệch thời gian thực / chạy trong thế giới thực so với hành vi dự đoán (tôi có dám nói là 'dự kiến' không?), Ví dụ: mất kiểm soát phương tiện khi lái xe.

Rõ ràng, một lỗi có thể gây ra một ngoại lệ như ví dụ trong 1) có thể dẫn đến ví dụ trong 2). Nhưng không phải tất cả các trường hợp ngoại lệ sẽ được gây ra bởi các lỗi, ví dụ, mất kiểm soát phương tiện vì người điều khiển bị đột quỵ.

Vì câu hỏi này đã được mở lại để lấy tiền thưởng, hãy để tôi đề cập đến bài viết CUJ của tôi từ năm 2003 có tựa đề "Ngoại lệ hay lỗi?", Có vẻ như giải quyết chính xác câu hỏi của OP.

Về cơ bản, bài viết định nghĩa các thuật ngữ "lỗi" và "ngoại lệ" (đưa ra ví dụ) và đề xuất các chiến lược để xử lý từng thuật ngữ.

Bài báo đề xuất không "xử lý" các lỗi mà thay vào đó đánh dấu chúng bằng các xác nhận. Ngược lại, các ngoại lệ thực sự yêu cầu xử lý thông qua mã (có thể ném / bắt ngoại lệ).

Điểm chính là các lỗi đòi hỏi chiến lược ngược lại chính xác hơn các trường hợp ngoại lệ.

Bài viết đã nói ở trên hiện có sẵn từ Dr.Dobb's tại: http://www.drdobbs.com/an-exception-or-a-orms/184401686