ควรตรวจสอบข้อผิดพลาดเล็ก ๆ น้อย ๆ ใน C หรือไม่?

ในฐานะโปรแกรมเมอร์ที่ดีคนหนึ่งควรเขียนโค้ดที่มีประสิทธิภาพซึ่งจะจัดการกับผลลัพธ์ทุกรายการของโปรแกรมของเขา อย่างไรก็ตามฟังก์ชันเกือบทั้งหมดจากไลบรารี C จะส่งคืนค่า 0 หรือ -1 หรือ NULL เมื่อมีข้อผิดพลาด

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

if(fprintf(stderr, "%s", errMsg) < 0){
    perror("An error occurred while displaying the previous error.");
    exit(1);
}

เป็นการดีหรือไม่ที่จะละเว้นข้อผิดพลาดบางอย่างหรือมีวิธีที่ดีกว่าในการจัดการข้อผิดพลาดทั้งหมดหรือไม่

โดยทั่วไปรหัสควรจัดการกับเงื่อนไขพิเศษทุกที่ที่เหมาะสม ใช่นี่เป็นข้อความที่คลุมเครือ

ในภาษาระดับสูงที่มีการจัดการข้อยกเว้นซอฟต์แวร์มักระบุว่า "ตรวจจับข้อยกเว้นในวิธีที่คุณสามารถทำอะไรกับมันได้จริง" หากเกิดข้อผิดพลาดของไฟล์คุณอาจปล่อยให้สแต็กขึ้นกับรหัส UI ที่สามารถบอกผู้ใช้ว่า "ไฟล์ของคุณล้มเหลวในการบันทึกลงดิสก์" กลไกการยกเว้นได้อย่างมีประสิทธิภาพกลืน "ข้อผิดพลาดเล็ก ๆ น้อย ๆ " และจัดการโดยปริยายในสถานที่ที่เหมาะสม

ใน C คุณไม่มีความหรูหรานั้น มีสองสามวิธีในการจัดการข้อผิดพลาดซึ่งบางส่วนเป็นคุณสมบัติภาษา / ไลบรารีบางวิธีเป็นการเขียนโค้ด

เป็นการดีหรือไม่ที่จะละเว้นข้อผิดพลาดบางอย่างหรือมีวิธีที่ดีกว่าในการจัดการข้อผิดพลาดทั้งหมดหรือไม่

ละเว้นข้อผิดพลาดบางอย่างหรือไม่ อาจจะ. ตัวอย่างเช่นมีเหตุผลที่จะสมมติว่าการเขียนไปยังเอาต์พุตมาตรฐานจะไม่ล้มเหลว ถ้ามันล้มเหลวคุณจะบอกผู้ใช้อย่างไร? ใช่เป็นความคิดที่ดีที่จะเพิกเฉยต่อข้อผิดพลาดบางอย่างหรือใช้รหัสเพื่อป้องกันข้อผิดพลาด ตัวอย่างเช่นตรวจสอบศูนย์ก่อนที่จะแบ่ง

มีวิธีจัดการข้อผิดพลาดทั้งหมดหรืออย่างน้อยที่สุด:

1. คุณสามารถใช้กระโดดคล้ายกับ gotos สำหรับจัดการข้อผิดพลาด ในขณะที่ปัญหาการโต้เถียงในหมู่ผู้เชี่ยวชาญซอฟต์แวร์มีการใช้งานที่ถูกต้องสำหรับพวกเขาโดยเฉพาะอย่างยิ่งในรหัสฝังตัวและประสิทธิภาพที่สำคัญ (เช่นเคอร์เนล Linux)

2. การเรียงซ้อนifs:

   if (!<something>) {
     printf("oh no 1!");
     return;
   }
   if (!<something else>) {
     printf("oh no 2!");
     return;
   }
   

3. ทดสอบเงื่อนไขแรกเช่นการเปิดหรือสร้างไฟล์จากนั้นถือว่าการดำเนินการที่ตามมาสำเร็จ

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

อย่างไรก็ตามฟังก์ชันเกือบทั้งหมดจากไลบรารี C จะส่งคืนค่า 0 หรือ -1 หรือ NULL เมื่อมีข้อผิดพลาด

ใช่ แต่คุณรู้ว่าฟังก์ชั่นที่คุณโทรหาใช่ไหม?

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

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

TLDR; คุณแทบไม่ควรละเลยข้อผิดพลาดเลย

ภาษา C ขาดคุณสมบัติการจัดการข้อผิดพลาดที่ดีทำให้ผู้พัฒนาห้องสมุดแต่ละรายใช้โซลูชันของตนเอง ภาษาสมัยใหม่มากขึ้นมีข้อยกเว้นที่สร้างขึ้นซึ่งทำให้ปัญหานี้ง่ายต่อการจัดการมากขึ้น

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

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

อย่างไรก็ตามในฐานะนักพัฒนาซอฟต์แวร์ C คุณต้องดูแลรักษาโค้ดให้ง่าย ดังนั้นบางครั้งคุณสามารถละเว้นข้อผิดพลาดได้อย่างปลอดภัยเพื่อความชัดเจนถ้า (และเฉพาะในกรณี) พวกเขาจะไม่เป็นภัยคุกคามต่อพฤติกรรมโดยรวมของแอปพลิเคชัน .

มันเป็นปัญหาแบบเดียวกันกับที่ทำสิ่งนี้:

try
{
    run();
} catch (Exception) {
    // comments expected here!!!
}

หากคุณเห็นว่าไม่มีความคิดเห็นที่ดีภายในบล็อก catch ว่างนี่เป็นปัญหาอย่างแน่นอน ไม่มีเหตุผลที่จะคิดว่าการเรียกร้องให้malloc()ดำเนินการสำเร็จ 100% ของเวลา

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

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

อีกวิธีที่คล้ายกันคือคุณสามารถปรับปรุงสถานะโดยการจับข้อผิดพลาดได้จริงเพียงใด ฉันไม่สามารถนับจำนวนโปรแกรม C ++ ที่จับข้อยกเว้นอย่างภาคภูมิใจเท่านั้นที่จะรื้อฟื้นพวกเขาเพราะพวกเขาไม่รู้ว่าจะทำอย่างไรกับพวกเขาจริง ๆ ... แต่พวกเขารู้ว่าพวกเขาควรจะจัดการกับข้อยกเว้น โปรแกรมดังกล่าวไม่ได้รับความพยายามใด ๆ เป็นพิเศษ เพิ่มรหัสตรวจสอบข้อผิดพลาดที่คุณคิดว่าอาจจัดการกับสถานการณ์ได้ดีกว่าการไม่ตรวจสอบรหัสข้อผิดพลาดเท่านั้น ที่ถูกกล่าวว่า C ++ มีกฎเฉพาะสำหรับการจัดการข้อยกเว้นที่เกิดขึ้นในระหว่างการจัดการข้อยกเว้นเพื่อที่จะจับพวกมันด้วยวิธีที่มีความหมายมากขึ้น (และโดยที่ฉันหมายถึงการโทรยุติ () เพื่อให้แน่ใจว่า ด้วยรัศมีภาพที่เหมาะสม)

คุณจะได้รับทางพยาธิวิทยาอย่างไร ฉันทำงานในโปรแกรมที่กำหนด "SafetyBool" ซึ่งมีค่าจริงและเท็จที่เลือกอย่างระมัดระวังเพื่อให้มีการแจกแจง 1 และ 0 อย่างสม่ำเสมอและพวกเขาได้รับเลือกเพื่อให้หนึ่งในจำนวนของความล้มเหลวของฮาร์ดแวร์ใด ๆ (flips บิตเดียวบัสข้อมูล ร่องรอยการแตกหัก ฯลฯ ) ไม่ได้ทำให้เกิดการตีความผิดทางบูลีน ไม่จำเป็นต้องพูดว่าฉันจะไม่เรียกร้องสิ่งนี้ว่าเป็นแบบฝึกหัดการเขียนโปรแกรมวัตถุประสงค์ทั่วไปที่จะใช้ในโปรแกรมเก่า ๆ

• ข้อกำหนดด้านความปลอดภัยที่แตกต่างกันต้องการระดับความถูกต้องที่แตกต่างกัน ในซอฟต์แวร์ควบคุมการบินหรือรถยนต์ค่าส่งคืนทั้งหมดจะถูกตรวจสอบ cf MISRA.FUNC.UNUSEDRET ในการพิสูจน์แนวคิดอย่างรวดเร็วซึ่งไม่เคยออกจากเครื่องของคุณอาจจะไม่
• เวลาการเข้ารหัสค่าใช้จ่าย การตรวจสอบที่ไม่เกี่ยวข้องจำนวนมากเกินไปในซอฟต์แวร์ที่ไม่ปลอดภัยเป็นสิ่งสำคัญคือความพยายามในการใช้จ่ายที่อื่นดีกว่า แต่จุดหวานระหว่างคุณภาพและราคาคืออะไร? ขึ้นอยู่กับเครื่องมือการดีบักและความซับซ้อนของซอฟต์แวร์
• การจัดการข้อผิดพลาดสามารถปิดบังขั้นตอนการควบคุมและแนะนำข้อผิดพลาดใหม่ ฉันค่อนข้างชอบฟังก์ชันห่อหุ้มของ "เครือข่าย" ของ Stevens ซึ่งอย่างน้อยก็รายงานข้อผิดพลาด
• การจัดการข้อผิดพลาดอาจเป็นปัญหาด้านประสิทธิภาพได้บ่อยครั้ง แต่การเรียกใช้ไลบรารี่ C ส่วนใหญ่จะใช้เวลานานกว่าค่าใช้จ่ายในการตรวจสอบค่าส่งคืนนั้นมีน้อยมาก

มีคำถามเล็กน้อยเกี่ยวกับคำถาม และมันก็ไม่จำเป็นสำหรับภาษา C

สำหรับโปรแกรมที่ใหญ่ขึ้นคุณจะมีเลเยอร์นามธรรม อาจเป็นส่วนหนึ่งของเครื่องยนต์ห้องสมุดหรือภายในกรอบ ชั้นที่จะไม่สนใจเกี่ยวกับสภาพอากาศที่คุณจะได้รับข้อมูลที่ถูกต้องหรือการส่งออกจะมีบางค่าเริ่มต้น: 0, -1, nullฯลฯ

จากนั้นก็มีเลเยอร์ที่จะเป็นส่วนต่อประสานของคุณไปยังเลเยอร์นามธรรมที่จะทำการจัดการข้อผิดพลาดจำนวนมากและบางทีสิ่งอื่น ๆ เช่นการฉีดพึ่งพาการฟังเหตุการณ์ ฯลฯ

และหลังจากนั้นคุณจะมีเลเยอร์การใช้งานที่เป็นรูปธรรมที่คุณตั้งค่ากฎและจัดการเอาต์พุต

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

นี่คือส่วนใหญ่ทำเพื่อแยกความรับผิดชอบที่นำไปสู่การอ่านรหัสและความยืดหยุ่นที่ดีขึ้น

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