สถานะการออกที่ไม่เป็นศูนย์สำหรับการออกที่สะอาด

เป็นที่ยอมรับหรือไม่ที่จะส่งคืนรหัสออกที่ไม่ใช่ศูนย์หากโปรแกรมที่เป็นปัญหารันได้อย่างถูกต้องหรือไม่? ตัวอย่างเช่นสมมติว่าฉันมีโปรแกรมอย่างง่าย ๆ ที่ (เท่านั้น) ทำสิ่งต่อไปนี้:

โปรแกรมรับอาร์กิวเมนต์ N มันจะส่งคืนรหัสทางออกของนาที (N, 255) โปรดทราบว่า N ใด ๆ ที่ถูกต้องสำหรับโปรแกรม

โปรแกรมที่สมจริงยิ่งขึ้นอาจส่งคืนรหัสที่แตกต่างกันสำหรับการรันโปรแกรมที่ประสบความสำเร็จซึ่งมีความหมายต่างกัน โปรแกรมเหล่านี้ควรเขียนข้อมูลนี้ไปยังสตรีมแทนเช่น stdout หรือไม่

มันขึ้นอยู่กับสภาพแวดล้อม แต่ฉันบอกว่ามันเป็นสไตล์ที่ไม่ดี

ระบบที่คล้าย Unix มีข้อตกลงที่รัดกุมซึ่งสถานะการออกเป็น 0 หมายถึงความสำเร็จและสถานะการออกที่ไม่ใช่ศูนย์ใด ๆ แสดงถึงความล้มเหลว โปรแกรมบางตัว แต่ไม่ทั้งหมดแยกแยะความแตกต่างระหว่างความล้มเหลวที่แตกต่างกันด้วยรหัสการออกที่ไม่เป็นศูนย์ที่แตกต่างกัน เช่นgrepโดยทั่วไปแล้วจะส่งกลับ 0 หากพบรูปแบบ, 1 ถ้าไม่ใช่และ 2 (หรือมากกว่า) หากมีข้อผิดพลาดเช่นไฟล์ที่ขาดหายไป

การประชุมนี้มีสายสวยมากในหอย Unix ตัวอย่างเช่น, in sh, bashและ shell-like Bourne อื่น ๆifคำสั่งจะถือว่าสถานะการออก 0 เป็นความสำเร็จ / true และสถานะทางออกที่ไม่ใช่ศูนย์ว่าเป็นความล้มเหลว / เท็จ:

if your-command
then
    echo ok
else
    echo FAILURE
fi

ฉันเชื่อว่าอนุสัญญาภายใต้ MS Windows นั้นคล้ายกัน

ตอนนี้ไม่มีอะไรหยุดคุณจากการเขียนโปรแกรมของคุณเองที่ใช้รหัสทางออกที่ผิดปกติโดยเฉพาะอย่างยิ่งถ้าไม่มีอะไรจะโต้ตอบกับมัน แต่ระวังให้ดีว่าคุณกำลังละเมิดข้อตกลงที่จัดตั้งขึ้นเป็นอย่างดีและอาจกลับมากัดคุณในภายหลัง .

วิธีปกติสำหรับโปรแกรมที่จะส่งคืนข้อมูลประเภทนี้คือการพิมพ์ไปที่stdout:

status = $(your-command)
echo Result is $status

ขึ้นอยู่กับสภาพแวดล้อมของคุณคาดหวัง

สิ่งที่ฉันชอบที่สุดสำหรับความแปลกประหลาดจากวิกิพีเดีย :

ใน OpenVMS ความสำเร็จจะถูกระบุด้วยค่าคี่และความล้มเหลวโดยค่าคู่ ค่าเป็นจำนวนเต็ม 32 บิตพร้อมฟิลด์ย่อย: บิตควบคุมหมายเลขเครื่องมืออำนวยความสะดวกหมายเลขข้อความและความรุนแรง ค่าความรุนแรงจะถูกแบ่งระหว่างความสำเร็จ (สำเร็จข้อมูล) และความล้มเหลว (คำเตือนข้อผิดพลาดร้ายแรง)

ฉันคิดว่ามีแบบอย่างถ้ารหัสทางออกกลับมามีความหมายข้อมูลที่เกี่ยวข้องกับผู้โทรและความหมายของความสำเร็จไม่ได้เป็นแบบไบนารีจริงๆ ก่อนหน้านี้ฉันคิดว่าการเป็นrobocopy ซึ่งผลตอบแทนการฆ่าของสิ่งที่แตกต่างกันขึ้นอยู่กับสิ่งที่เกิดขึ้น

ฉันจะเพิ่มว่าเรามักจะมีการแก้จุดบกพร่องเพราะสิ่งนี้ - ยูทิลิตี้ส่วนใหญ่ถือว่ารหัสทางออก 0 == ประสบความสำเร็จดังนั้นรับ freaked เมื่อ robocopy กลับ 1 เพราะมันคัดลอกสิ่งที่ไม่เป็นศูนย์เพราะมันไม่ได้คัดลอกเนื้อหา ไม่ได้รับข้อผิดพลาดอย่างใดอย่างหนึ่ง

การไม่ส่งคืน 0 สำหรับการเรียกใช้ที่ประสบความสำเร็จเป็นความคิดที่ไม่ดีเพราะอาจทำให้เกิดความสับสนสำหรับผู้ที่รันโปรแกรมของคุณ จะเกิดอะไรขึ้นถ้าบางคนรันโปรแกรมของคุณ 100 + ครั้งด้วยการป้อนข้อมูลที่แตกต่างกันและต้องการทราบว่าล้มเหลวหรือเสร็จสิ้นสมบูรณ์มากน้อยเพียงใดการมีค่าความสำเร็จเพียงครั้งเดียว

หากคุณมีโปรแกรมที่มีเส้นทางการส่งคืนที่ประสบความสำเร็จหลายอย่างซึ่งทุกคนสามารถบ่งบอกถึงสิ่งที่แตกต่างกันฉันจะบอกว่านั่นเป็นสัญญาณที่โปรแกรมของคุณออกแบบมาไม่ดี

ฉันรู้กรณีที่ฉันคิดว่าเป็นที่ยอมรับ ฉันรู้ถึงกรอบการทดสอบที่ออกมาพร้อมกับจำนวนการทดสอบที่ล้มเหลว ตัวอย่างเช่นหากผู้ทดสอบเสร็จสิ้นโดยไม่มีการทดสอบที่ล้มเหลวก็จะออกจากศูนย์ หากการทดสอบหนึ่งล้มเหลวแม้ว่าผู้ทดสอบจะวิ่งอย่างคล่องแคล่วมันจะออกมาพร้อมกับ 1 หากการทดสอบสองครั้งล้มเหลวจะส่งคืน 2 เป็นต้นซึ่งจะสูงถึง 250 ซึ่งหมายความว่า "การทดสอบล้มเหลว 250 ครั้งหรือมากกว่า"

มันใช้รหัสทางออก> 250 เพื่อแสดงว่าทางออกผิดปกติ

ในขณะที่นี่เป็นการละเมิดการประชุมมันทำงานได้ดีในทางปฏิบัติ

มันขึ้นอยู่กับสิ่งที่คุณพยายามถ่ายทอดด้วยรหัส ตัวอย่างเช่น DB2 จะส่งคืน 100 หากไม่พบข้อมูลค่าบวกอื่น ๆ อีกมากมายสำหรับคำเตือนและค่าลบสำหรับข้อผิดพลาด Oracle ทำสิ่งที่คล้ายกัน

ดังนั้นหากมีสถานะความสำเร็จแตกต่างกันมันอาจจะคุ้มค่าหากใช้ค่าส่งคืนที่ต่างกัน

ตัวอย่างที่ดี: man sa-update (spamassassin)

ออกจากโคด

• รหัสทางออก 0 หมายถึงการอัปเดตพร้อมใช้งานและถูกดาวน์โหลดและติดตั้งสำเร็จหากไม่ได้ระบุ --checkonly
• รหัสทางออก 1 หมายถึงไม่มีการอัพเดทใหม่
• รหัสทางออก 2 หมายถึง ...

ในกรณีนี้ทางออก 1 เป็นเพียงรหัสข้อมูล อย่างไรก็ตามหากฉันจะเขียนรหัสฉันจะไม่เลือก 1 เนื่องจากความล้มเหลวหลัก