Khi nào thích hợp để sử dụng mã lỗi?

Question

Trong các ngôn ngữ hỗ trợ các đối tượng ngoại lệ (Java, C#), khi nào thích hợp để sử dụng error codes? Việc sử dụng mã lỗi có phù hợp với các ứng dụng doanh nghiệp điển hình không?

Nhiều hệ thống phần mềm nổi tiếng sử dụng mã lỗi (và tham chiếu mã lỗi tương ứng). Một số ví dụ bao gồm các hệ điều hành (Windows), cơ sở dữ liệu (Oracle, DB2) và các sản phẩm phần giữa (WebLogic, WebSphere). Mã lỗi cung cấp những lợi ích gì? Những bất lợi khi sử dụng mã lỗi là gì?

Answer 1

WITHIN một chương trình luôn phải sử dụng ngoại lệ thay vì mã lỗi. Tuy nhiên, các ngoại lệ không thể lan truyền ngoài chương trình. Bất cứ khi nào lỗi phải rời khỏi chương trình bạn bị bỏ sót với thông báo lỗi hoặc mã lỗi.

Đối với những thứ đơn giản sẽ luôn luôn là thông báo lỗi do con người vận hành mà không có mã là tốt. Bạn có thể nói "Không tìm thấy tệp" mà không cung cấp mã lỗi. Tuy nhiên, nếu nó có thể là một máy tính khác ở đầu bên kia thì bạn cũng nên cung cấp mã lỗi. Bạn không muốn phá vỡ hệ thống khác khi bạn thay đổi nó thành "File <x> không tìm thấy".

Answer 2

Mã lỗi là trường học cũ. Họ có ít hoặc không có giá trị gì cả.

Giá trị duy nhất có thể cho mã lỗi là nó có thể xác định một trường hợp rất cụ thể. Bạn có thể có một mã cho mỗi điểm trong cơ sở mã có thể ném một ngoại lệ. Điều này sẽ cho phép bạn thu hẹp chính xác vấn đề phải là gì.

Nhưng không ai quan tâm đến mức chi tiết đó. Ai muốn duy trì một mớ hỗn độn như vậy. Nó sẽ để lại cho bạn với các mã có nghĩa là một cái gì đó như "điều kiện A và B nhưng không phải C do nhà nước S". Đó là nỗ lực nhiều hơn nó có giá trị để cố gắng tìm ra chính xác những gì có nghĩa là. Một dấu vết ngăn xếp sẽ có giá trị hơn trong việc cho bạn biết nơi trong chương trình vấn đề xảy ra.

Tôi đã học cách lập trình máy tính trước khi ngoại lệ là một kỹ thuật phổ biến. Tôi là vì vậy, rất vui vì chúng tôi có ngoại lệ!

Answer 3

Tôi không nghĩ rằng tôi đã từng sử dụng các mã lỗi trong Net trừ một tình - khi tôi đã tạo ra một ứng dụng giao diện điều khiển mà tôi biết được sẽ được gọi từ ứng dụng khác. Ứng dụng khác này phải biết khi ứng dụng bảng điều khiển bị lỗi và điều gì đã xảy ra. Vì vậy, một ví dụ về khi nào nó sẽ là thích hợp sẽ là khi bạn biết chương trình của bạn sẽ được gọi bởi các chương trình khác, và bạn muốn có một cách có cấu trúc để họ hiểu lỗi.

Điều đó nói rằng, tôi là người mới vào .NET vào thời điểm đó và chưa bao giờ sử dụng mã lỗi kể từ đó.

Như một lưu ý phụ, là một anh chàng Windows, thật tuyệt khi có thể viết mã lỗi và đưa ra bài viết KB, vì vậy mã lỗi kết hợp với tài liệu tốt và khả năng tìm thấy nó từ người dùng của bạn.

Answer 4

Tôi thường xuyên sử dụng mã lỗi khi lỗi cần được chuyển tải tới người dùng vì chúng có thể được quốc tế hóa. Ví dụ, trong trình biên dịch, nếu có lỗi trong mã người dùng, các lỗi có thể được báo hiệu trong trình phụ trợ của trình biên dịch, trong khi giao diện người dùng có thể bản địa hóa chúng thành các chuỗi văn bản/ngôn ngữ cụ thể để người dùng sử dụng. Enums có thể tốt hơn cho mục đích này hơn là nguyên nguyên, tuy nhiên.

Tôi cũng đã sử dụng chúng trong việc tạo khung "báo cáo lỗi" cho ứng dụng. Khi các ngoại lệ được ném ra, chúng được ném với một mã lỗi, khi mà trường hợp ngoại lệ phát sinh, được gửi (với một bản ghi) đến máy chủ trung tâm. Mã đã giúp tổ chức cơ sở dữ liệu để chúng tôi có thể kiểm tra các nhật ký liên quan đến một lỗi cụ thể.

Cuối cùng, như đã đề cập trong một vài câu trả lời khác, mã lỗi rất dễ hiểu và không có khả năng ngôn ngữ với google (nghĩ mã lỗi Windows/bài viết MS KB), do đó, mã lỗi với mô tả sự cố có thể là tốt hơn cho người dùng cuối của một sản phẩm kỹ thuật.

Ý tưởng về mã lỗi rất hữu ích, nhưng IMO chúng thuộc về thành viên ngoại lệ hoặc làm tham số cho giao diện IErrorReporter hoặc thứ gì đó khác hơn là giá trị trả về của phương thức.

Answer 5

Rất phổ biến cho các giao diện dịch vụ web. Nó rất dễ dàng và tiêu chuẩn để trả về một mã với một mô tả.

Tôi đồng ý rằng đối với hầu hết các trường hợp là trường học cũ

Tôi muốn nói những bất lợi lớn nhất đó là chất lượng mã. Bạn phải thêm logic phức tạp hơn để quản lý các mã lỗi trong khi các ngoại lệ được kích thích mà không phải sử dụng các tham số phương thức hoặc các giá trị trả về.

Bạn cũng phải thêm "IF" để kiểm tra xem mã trả về có THÀNH CÔNG hay không, trong khi ngoại lệ đi trực tiếp đến khối xử lý lỗi.

Answer 6

C#, và có lẽ cả Java nữa, hỗ trợ luồng kiểm soát xử lý ngoại lệ tốt hơn, từ khóa cuối cùng, làm cho mọi thứ đẹp hơn một chút so với sử dụng mã lỗi. Một đối tượng ngoại lệ có thể chứa bất kỳ mức độ chi tiết nào, chắc chắn nhiều hơn một mã lỗi. Vì vậy, các đối tượng ngoại lệ là cách thực tế hơn, nhưng bạn có thể chạy vào một trường hợp không phổ biến, nơi một mã lỗi sẽ là thích hợp hơn.

FWIW, C++ cũng hỗ trợ các đối tượng ngoại lệ. Tôi không nghĩ rằng C + + hỗ trợ một từ khóa cuối cùng (mặc dù mới hơn C + + whatevers chỉ có thể), nhưng trong C + + bạn cũng phải tránh những thứ như trở về bên trong một xử lý bắt.

Answer 7

Tôi là một newbie để ngăn xếp tràn nhưng ...

Tôi tin rằng mã lỗi có xu hướng được sử dụng hoặc hữu ích để đối phó với các tình huống sai lầm mà yêu cầu một người dùng cuối của các loại để tham gia để khắc phục một tình hình. Nếu mã của bạn được duy trì bởi một nhà phát triển khác thì ngoại lệ là cách để đi. Tuy nhiên, trong một tình huống mà có một vấn đề:

• trong môi trường ứng dụng của bạn đang chạy

• với thông tin liên lạc giữa các ứng dụng của bạn và một số đối tượng khác (máy chủ web, cơ sở dữ liệu, ổ cắm, vv)

• rằng một trình điều khiển thiết bị hoặc điện thoại chỉ báo (lỗi phần cứng có lẽ?)

sau đó mã lỗi có thể có ý nghĩa. Ví dụ: nếu ứng dụng của bạn cố gắng đăng nhập vào cơ sở dữ liệu thay mặt cho người dùng cuối của bạn, nhưng DB không thể truy cập được để xác thực (DB bị ngắt kết nối, cáp được rút phích cắm) thì mã lỗi/mô tả kết hợp có thể giúp kết thúc- người dùng khắc phục sự cố.

Một lần nữa ở cấp nhà phát triển/kỹ sư, người sẽ có thể chạm vào mã nguồn (kỹ thuật gỡ lỗi và thử nghiệm truyền thống) và sửa đổi nó, sử dụng ngoại lệ.

Hy vọng điều này sẽ giúp ...

--jqpdev

Answer 8

Tôi đã viết nhiều dịch vụ web được tiêu thụ bởi các ứng dụng (từ xa) khác. Khi mọi thứ trở nên tồi tệ với một yêu cầu, khách hàng ngày càng ít nhấn mạnh vào việc nhận được một mã, để họ không phải làm một số so sánh chuỗi khủng khiếp để tìm hiểu những gì đã đi sai.

Lấy mã kết quả HTTP làm ví dụ tốt về loại hành vi này. "200" có nghĩa là hạnh phúc, "300" có thể đi theo một trong hai cách, "400" hoặc "500" có nghĩa là bắt đầu freaking ra.

Answer 9

Mã lỗi được thiết kế ở độ tuổi mà cách duy nhất để chức năng báo cho người gọi biết rằng đã xảy ra sự cố với một hoặc nhiều giá trị có thể trả lại và rất thường xuyên số nguyên hoặc như vậy đã có sẵn để trả về giá trị đặc biệt đó.

Ví dụ, trong C, thường trình "nhận được ký tự" trả về giá trị ký tự tiếp theo trong ASCII, nhưng trả về giá trị âm nếu vì lý do nào đó đã xảy ra sự cố. Sau đó, bạn chịu trách nhiệm trả lại cho người gọi CỦA BẠN theo cách để tình trạng lỗi này có thể được xử lý và phải trả lại ...

Cơ chế ngoại lệ là cách thanh lịch để xử lý "đây là trường hợp khẩn cấp, chúng tôi phải quay lại cho đến khi có điều gì đó có thể giải quyết được vấn đề ". Mã lỗi kém hơn điều này.

Answer 10

Mã lỗi cho nếu bạn muốn gửi chúng cho người dùng. Nếu không, hãy sử dụng một ngoại lệ.