Có điều gì như một bộ mã trả về ứng dụng chuẩn không? Những điều như trở về 0 cho thành công 1 cho thất bại, và sau đó như vậy?Mã trả về/thoát ứng dụng "chuẩn" nào cần hỗ trợ ứng dụng?
Tôi có một ứng dụng Windows Server mà tôi đang thêm một số mã lỗi trả về và muốn gắn vào mã tiêu chuẩn ngoài các mã ứng dụng cụ thể mà tôi sẽ cần.
Không có điều gì như một bộ mã thoát tiêu chuẩn mà các ứng dụng phải tuân theo.
Tuy nhiên, có một số thông thường như 0 để thành công như bạn đã đề cập. Tùy thuộc vào Hệ điều hành và công cụ bạn sử dụng, bạn có thể xem mã thoát cho các ứng dụng tương tự và bắt chước chúng.
Tôi nghĩ tiêu chuẩn duy nhất là 0 cho thành công và khác không cho thất bại. Và đó là một quy ước hơn là một tiêu chuẩn.
Mã thoát nằm ngoài tiêu chuẩn và được sử dụng nhiều hơn cho nhà phát triển để biết lỗi thích hợp đã xảy ra khi trả lại ứng dụng. Tiêu chuẩn 0 cho thành công, khác không cho thất bại là một xu hướng chung, và được sử dụng vì nó cho phép bạn sử dụng phạm vi không khác đầy đủ cho tất cả các lỗi có thể xảy ra.
Nếu ứng dụng của bạn ghi lại các lỗi một cách thích hợp, mã thoát sẽ có khả năng hoàn toàn không cần thiết để theo dõi.
Mã trạng thái chuẩn là EXIT_SUCCESS và EXIT_FAILURE, được xác định trong stdlib.h. Khá nhiều người chỉ sử dụng 0 và 1 tương ứng, mặc dù. Một số phần mềm sẽ sử dụng mã không khác nhau cho các loại lỗi khác nhau.
Triển khai những gì bạn sẽ sử dụng. Bất cứ điều gì khác là thừa.
Có thể bạn có thể áp dụng một số quy ước của Unix.
Trong another answer, người dùng David đề nghị
sysexits.hcó một danh sách các mã lối ra tiêu chuẩn. Có vẻ như ngày trở lại ít nhất năm 1993 và một số dự án lớn như Postfix sử dụng nó, vì vậy tôi tưởng tượng đó là con đường để đi.Từ trang người đàn ông OpenBSD:
Theo phong cách (9), nó không phải là thực hành tốt để gọi exit (3) với giá trị trary arbi- để chỉ một tình trạng thất bại khi kết thúc một chương trình. Thay vào đó, các mã thoát được xác định trước từ sysexits nên được sử dụng, vì vậy người gọi của quá trình có thể nhận được một ước tính sơ bộ về lớp lỗi mà không tra cứu mã nguồn.
Đây là danh sách như nó xuất hiện trên một hệ thống Debian:
#define EX_USAGE 64 /* command line usage error */
#define EX_DATAERR 65 /* data format error */
#define EX_NOINPUT 66 /* cannot open input */
#define EX_NOUSER 67 /* addressee unknown */
#define EX_NOHOST 68 /* host name unknown */
#define EX_UNAVAILABLE 69 /* service unavailable */
#define EX_SOFTWARE 70 /* internal software error */
#define EX_OSERR 71 /* system error (e.g., can't fork) */
#define EX_OSFILE 72 /* critical OS file missing */
#define EX_CANTCREAT 73 /* can't create (user) output file */
#define EX_IOERR 74 /* input/output error */
#define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */
#define EX_PROTOCOL 76 /* remote error in protocol */
#define EX_NOPERM 77 /* permission denied */
#define EX_CONFIG 78 /* configuration error */
Bên trong tập tin /usr/include/sysexits.h người ta có thể tìm thấy mô tả chi tiết hơn về các mã lỗi.
Đây là những gì tôi sử dụng. – RedShift
Chắc chắn có các mã lỗi chuẩn được xác định cho Windows.
Một thời gian dài trước đây, chúng tôi đã sử dụng các lỗi tiêu cực cho các lỗi 'tùy chỉnh' cụ thể, nhưng tôi nghi ngờ rằng đó là thực hành tốt.
Bạn không cần sử dụng * Mã lỗi hệ thống * làm mã thoát chương trình. Như đã lưu ý trong các câu trả lời khác ở đây, thông thường cho các chương trình Windows sử dụng * 1 * làm mã lỗi toàn bộ; nếu mọi người đang sử dụng * Mã lỗi hệ thống *, điều đó luôn có nghĩa là "Chức năng không chính xác" (và sẽ không có cách nào để chỉ ra lỗi chung không xác định). –
Đó là sự thật, bạn không cần phải tuân thủ các tiêu chuẩn. Câu hỏi là về tiêu chuẩn, và đó là những gì tôi đã cung cấp. Trường hợp cơ bản bằng 0 cho biết thành công, khác 0 cho biết lỗi. Nếu người gọi không thể xử lý các lỗi cụ thể, bạn sẽ không quan tâm lỗi là gì, nhưng nếu bạn mong đợi người gọi hành động thất bại, thực hành tốt là đưa ra các lỗi có ý nghĩa. Tiêu chuẩn giúp cung cấp cấu trúc trong trường hợp này. – Pyro
* "bạn không cần phải tuân thủ các tiêu chuẩn" * - đây không phải là một phần không liên tục; việc sử dụng Mã lỗi hệ thống làm mã thoát ứng dụng không có gì để "tuân thủ các tiêu chuẩn" vì không có tiêu chuẩn, ở bất kỳ đâu, điều đó gợi ý làm như vậy. * "nếu bạn mong đợi người gọi hành động thất bại, thực hành tốt để cung cấp lỗi có ý nghĩa" * - Tôi đồng ý, nhưng điều này không đạt được bằng cách sử dụng Mã lỗi hệ thống vì có hàng nghìn lỗi (vì vậy người gọi không thể xem xét chúng tất cả) và chúng có thể quá chung chung để mô tả lỗi ứng dụng cụ thể theo cách có ý nghĩa. –
Quy ước thực duy nhất là 0 nghĩa với thành công và khác không giá trị (thường 1) có nghĩa là thất bại. Đối với một tài liệu tham khảo chính thức về vấn đề này, xem, ví dụ, Microsoft C++ tài liệu trên exit:
Thông thường, người gọi đặt giá trị
status-0 để chỉ ra một lối ra bình thường, hoặc một số giá trị khác để chỉ ra một lỗi.
Hoặc C# docs trên Envrionment.Exit và Environment.ExitCode đó khác nhau như nhà nước:
Sử dụng 0 (zero) để chỉ ra rằng quá trình này kết thúc thành công.
và
Giá trị mặc định là 0 (zero), mà chỉ ra rằng quá trình này kết thúc thành công.
và
Sử dụng một số khác không để chỉ ra một lỗi. Trong ứng dụng của bạn, bạn có thể xác định mã lỗi của riêng bạn trong một liệt kê và trả về mã lỗi thích hợp dựa trên kịch bản. Ví dụ: trả lại giá trị 1 để cho biết rằng tệp được yêu cầu không có và giá trị là 2 để cho biết tệp có định dạng sai. Để biết danh sách các mã thoát được sử dụng bởi hệ điều hành Windows, hãy xem System Error Codes trong tài liệu Windows.
Không giống như some other answerers, tôi khuyên bạn không nên sử dụng System Error Codes như mã thoát ứng dụng. Một số lưu ý về System Error Codes:
dir, dotnet hoặc TAEF.
Liên kết của bạn bị hỏng và không nằm trong bộ nhớ cache của Google. (Ngoài ra, một bài đăng trên diễn đàn HP dường như không phải là một tài liệu tham khảo đặc biệt có thẩm quyền ở nơi đầu tiên.) –