ข้อโต้แย้งต่อต้านการปราบปรามข้อผิดพลาด

ฉันพบโค้ดบางส่วนในโครงการของเรา:

    SomeClass QueryServer(string args)
    {
        try
        {
            return SomeClass.Parse(_server.Query(args));
        }
        catch (Exception)
        {
            return null;
        }
    }

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

เมื่อใดที่เหมาะสมที่จะระงับข้อผิดพลาดทั้งหมดเช่นนี้

ลองนึกภาพโค้ดที่มีไฟล์นับพันไฟล์โดยใช้ไลบรารีหลาย ๆ ไฟล์ ลองนึกภาพทั้งหมดของพวกเขาถูกเข้ารหัสเช่นนี้

ลองจินตนาการถึงตัวอย่างเช่นการอัปเดตเซิร์ฟเวอร์ของคุณทำให้ไฟล์การกำหนดค่าหนึ่งไฟล์หายไป และตอนนี้สิ่งที่คุณมีคือการติดตามสแต็กเป็นข้อยกเว้นตัวชี้โมฆะเมื่อคุณลองใช้คลาสนั้น: คุณจะแก้ไขได้อย่างไร อาจใช้เวลาหลายชั่วโมงโดยที่อย่างน้อยการบันทึกการติดตามสแต็กดิบของไฟล์ที่ไม่พบ [เส้นทางของไฟล์] อาจทำให้คุณสามารถแก้ไขได้ในชั่วขณะ

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

แม้ไม่มีข้อผิดพลาดที่มีประสิทธิภาพการจัดการเพียงแค่ทำ

throw new IllegalStateException("THIS SHOULD NOT HAPPENING")

หรือ

LOGGER.error("[method name]/[arguments] should not be there")

อาจช่วยให้คุณประหยัดเวลาได้หลายชั่วโมง

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

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

แนวทางปฏิบัติที่ดีที่สุดคือสิ่งที่ต้องปฏิบัติตามในกรณีส่วนใหญ่อาจ 80% หรือ 99% แต่คุณจะพบกรณีขอบหนึ่งกรณีที่ไม่ได้ใช้ ในกรณีนี้แสดงความคิดเห็นว่าทำไมคุณไม่ปฏิบัติตามแบบฝึกหัดสำหรับคนอื่น (หรือแม้แต่ตัวคุณเอง) ที่จะอ่านรหัสของคุณในภายหลัง

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

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

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

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

   if(QueryServer(args)==null)
      TerminateProgram();

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

  result = QueryServer(args);
  if(result!=null)
      DoSomethingMeaningful(result);
  // else ??? Mask the error and let the user run into trouble later

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

ในปีที่ผ่านมาฉันใช้เวลาเขียนโปรแกรมและพัฒนาระบบมีเพียงสองสถานการณ์ที่ฉันพบรูปแบบที่เป็นประโยชน์ (ในทั้งสองกรณีการปราบปรามยังมีการบันทึกข้อยกเว้นการขว้างทิ้งไว้ฉันไม่พิจารณาจับแบบธรรมดาและnullกลับมาเป็นแนวทางปฏิบัติที่ดี )

ทั้งสองสถานการณ์มีดังต่อไปนี้:

1. เมื่อข้อยกเว้นไม่ถือเป็นสถานะพิเศษ

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

คุณลักษณะบางอย่างที่เป็นตัวเลือกของคลาสอาจอยู่ในใจ

2. เมื่อคุณให้การปรับใช้ไลบรารีใหม่ (ดีกว่าเร็วกว่า) โดยใช้อินเทอร์เฟซที่ใช้ในแอปพลิเคชันแล้ว

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

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

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

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

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

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

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

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

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

การกลืนข้อผิดพลาดประเภทนี้จะไม่มีประโยชน์กับทุกคนโดยเฉพาะ ใช่โทรเดิมอาจไม่สนใจเกี่ยวกับข้อยกเว้น แต่คนอื่นอาจจะ

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

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

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

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

ตัวอย่างเช่นวิธีการห้องสมุด

public foo findFoo() {...} 

ส่งคืน foo แรก แต่ถ้าไม่มีจะส่งข้อยกเว้น แต่สิ่งที่ฉันต้องการคือวิธีการคืนค่า foo หรือ null แรก ดังนั้นฉันจึงเขียนอันนี้:

public foo myFindFoo() {
    try {
        return findFoo() 
    } 
    catch (NoFooException ex) {
        return null;
    }
}

ไม่เรียบร้อย แต่บางครั้งวิธีแก้ปัญหาในทางปฏิบัติ