ลองจับหรือ ifs สำหรับการจัดการข้อผิดพลาดใน C ++

มีการใช้ข้อยกเว้นกันอย่างแพร่หลายในการออกแบบเกมเอ็นจิ้นหรือมันจะดีกว่าถ้าใช้ข้อความล้วน ๆ ? ตัวอย่างเช่นมีข้อยกเว้น:

try {
    m_fpsTextId = m_statistics->createText( "FPS: 0", 16, 20, 20, 1.0f, 1.0f, 1.0f );
    m_cpuTextId = m_statistics->createText( "CPU: 0%", 16, 20, 40, 1.0f, 1.0f, 1.0f );
    m_frameTimeTextId = m_statistics->createText( "Frame time: 0", 20, 20, 60, 1.0f, 1.0f, 1.0f );
    m_mouseCoordTextId = m_statistics->createText( "Mouse: (0, 0)", 20, 20, 80, 1.0f, 1.0f, 1.0f );
    m_cameraPosTextId = m_statistics->createText( "Camera pos: (0, 0, 0)", 40, 20, 100, 1.0f, 1.0f, 1.0f );
    m_cameraRotTextId = m_statistics->createText( "Camera rot: (0, 0, 0)", 40, 20, 120, 1.0f, 1.0f, 1.0f );
} catch ... {
    // some info about error
}

และด้วย ifs:

m_fpsTextId = m_statistics->createText( "FPS: 0", 16, 20, 20, 1.0f, 1.0f, 1.0f );
if( m_fpsTextId == -1 ) {
    // show error
}
m_cpuTextId = m_statistics->createText( "CPU: 0%", 16, 20, 40, 1.0f, 1.0f, 1.0f );
if( m_cpuTextId == -1 ) {
    // show error
}
m_frameTimeTextId = m_statistics->createText( "Frame time: 0", 20, 20, 60, 1.0f, 1.0f, 1.0f );
if( m_frameTimeTextId == -1 ) {
    // show error
}
m_mouseCoordTextId = m_statistics->createText( "Mouse: (0, 0)", 20, 20, 80, 1.0f, 1.0f, 1.0f );
if( m_mouseCoordTextId == -1 ) {
    // show error
}
m_cameraPosTextId = m_statistics->createText( "Camera pos: (0, 0, 0)", 40, 20, 100, 1.0f, 1.0f, 1.0f );
if( m_cameraPosTextId == -1 ) {
    // show error
}
m_cameraRotTextId = m_statistics->createText( "Camera rot: (0, 0, 0)", 40, 20, 120, 1.0f, 1.0f, 1.0f );
if( m_cameraRotTextId == -1 ) {
    // show error
}

ฉันได้ยินมาว่าข้อยกเว้นนั้นช้ากว่า ifs เล็กน้อยและฉันไม่ควรผสมข้อยกเว้นเข้ากับวิธีตรวจสอบ if อย่างไรก็ตามมีข้อยกเว้นฉันมีรหัสที่อ่านได้มากกว่ากับตันของ ifs หลังจากทุกวิธีการเริ่มต้น () หรือสิ่งที่คล้ายกันแม้ว่าบางครั้งพวกเขาจะหนักเกินไปสำหรับเพียงหนึ่งวิธีในความคิดของฉัน พวกเขาตกลงสำหรับการพัฒนาเกมหรือดีกว่าที่จะยึดติดกับไอเอฟเอง่าย?

คำตอบสั้น ๆ : อ่านการจัดการข้อผิดพลาดที่เหมาะสม 1 , การจัดการข้อผิดพลาดที่สมเหตุสมผล 2และการจัดการข้อผิดพลาดที่สมเหตุสมผล 3โดย Niklas Frykholm ที่จริงแล้วอ่านบทความทั้งหมดในบล็อกนั้นในขณะที่คุณอยู่ในนั้น จะไม่พูดว่าฉันเห็นด้วยกับทุกอย่าง แต่ส่วนใหญ่เป็นทองคำ

อย่าใช้ข้อยกเว้น มีเหตุผลมากมาย ฉันจะแสดงรายการที่สำคัญ

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

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

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

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

เกี่ยวกับรหัสเช่นตัวอย่างของคุณคุณมีหลายวิธีในการแก้ไขปัญหา หนึ่งในเครื่องมือที่มีประสิทธิภาพมากขึ้น - แต่ไม่จำเป็นต้องเหมาะสมที่สุดในตัวอย่างง่ายๆของคุณคือการพึ่งพาประเภทข้อผิดพลาดแบบ monadic นั่นคือ createText () สามารถส่งคืนชนิดของการจัดการที่กำหนดเองแทนที่จะเป็นจำนวนเต็ม ประเภทการจัดการนี้มี accessors สำหรับการปรับปรุงหรือควบคุมข้อความ หากหมายเลขอ้างอิงถูกทำให้อยู่ในสถานะข้อผิดพลาด (เนื่องจาก createText () ล้มเหลว) ดังนั้นการเรียกไปยังหมายเลขอ้างอิงเพิ่มเติมจะล้มเหลวอย่างเงียบ ๆ คุณสามารถสอบถามหมายเลขอ้างอิงเพื่อดูว่ามีข้อผิดพลาดหรือไม่และหากเป็นเช่นนั้นข้อผิดพลาดสุดท้ายคืออะไร วิธีนี้มีค่าใช้จ่ายมากกว่าตัวเลือกอื่น ๆ แต่ก็ค่อนข้างแข็ง ใช้มันในกรณีที่คุณต้องการดำเนินการสายยาวในบางบริบทที่การดำเนินการเดียวอาจล้มเหลวในการผลิต แต่ที่คุณทำไม่ได้ / ไม่สามารถ / ชนะ '

อีกทางเลือกหนึ่งในการนำการจัดการข้อผิดพลาดแบบ monadic มาใช้แทนการใช้ออบเจ็กต์หมายเลขอ้างอิงแบบกำหนดเองทำให้เมธอดบนออบเจ็กต์บริบทจัดการกับรหัสการจัดการที่ไม่ถูกต้องได้อย่างงดงาม ตัวอย่างเช่นถ้า createText () ส่งคืน -1 เมื่อล้มเหลวดังนั้นการเรียกอื่น ๆ ไปยัง m_statistics ที่ใช้หนึ่งในการจัดการเหล่านั้นควรจะออกอย่างสง่างามหากผ่าน -1

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

ตัวเลือกที่ดีที่สุด (นำเสนอในชุดบทความที่เชื่อมโยงด้านบนแล้ว) สำหรับการโทรที่คุณไม่คาดหวังว่าจะล้มเหลวในสภาพแวดล้อมที่มีสติเช่นการกระทำง่ายๆในการสร้าง blobs ข้อความสำหรับระบบสถิติ - คือการมีฟังก์ชั่น ที่ล้มเหลว (createText ในตัวอย่างของคุณ) ยกเลิก คุณสามารถมั่นใจได้ว่า createText () จะไม่ล้มเหลวในการผลิตเว้นแต่บางสิ่งจะถูกลบออกทั้งหมด (เช่นผู้ใช้ลบไฟล์ข้อมูลแบบอักษรหรือด้วยเหตุผลบางอย่างมีหน่วยความจำ 256MB เท่านั้น) ในหลายกรณีเหล่านี้ไม่มีแม้แต่สิ่งดีที่ต้องทำเมื่อเกิดความล้มเหลว ความจำเต็ม? คุณอาจไม่สามารถทำการจัดสรรที่จำเป็นเพื่อสร้างแผง GUI ที่ดีเพื่อแสดงข้อผิดพลาดของผู้ใช้ แบบอักษรหายไป? ทำให้ยากที่จะแสดงข้อผิดพลาดกับผู้ใช้ มีอะไรผิดปกติ

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

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

ภูมิปัญญาเก่าแก่ของ Donald Knuth คือ:

"เราควรลืมเกี่ยวกับความไร้ประสิทธิภาพเล็ก ๆ พูดถึง 97% ของเวลา: การเพิ่มประสิทธิภาพก่อนวัยอันควรเป็นรากฐานของความชั่วร้ายทั้งหมด"

พิมพ์สิ่งนี้เป็นโปสเตอร์ขนาดใหญ่และออกไปเที่ยวที่ไหนก็ได้ที่คุณเขียนโปรแกรมอย่างจริงจัง

ดังนั้นแม้ถ้าลอง / จับน้อยช้าแล้วฉันจะใช้มันโดยค่าเริ่มต้น:

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

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

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

ดังนั้นประเด็นสุดท้าย:

ฉันได้ยินมาว่าข้อยกเว้นนั้นช้ากว่า ifs เล็กน้อย

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

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

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

ฉันเชื่อว่ารหัสของคุณอาจมีลักษณะเช่นนี้:

m_fpsTextId = m_statistics->createText( "FPS: 0", 16, 20, 20, 1.0f, 1.0f, 1.0f );
m_cpuTextId = m_statistics->createText( "CPU: 0%", 16, 20, 40, 1.0f, 1.0f, 1.0f );
m_frameTimeTextId = m_statistics->createText( "Frame time: 0", 20, 20, 60, 1.0f, 1.0f, 1.0f );
m_mouseCoordTextId = m_statistics->createText( "Mouse: (0, 0)", 20, 20, 80, 1.0f, 1.0f, 1.0f );
m_cameraPosTextId = m_statistics->createText( "Camera pos: (0, 0, 0)", 40, 20, 100, 1.0f, 1.0f, 1.0f );
m_cameraRotTextId = m_statistics->createText( "Camera rot: (0, 0, 0)", 40, 20, 120, 1.0f, 1.0f, 1.0f );

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