เหตุใดจึงต้องจับและสร้างข้อยกเว้นขึ้นใหม่ใน C #

ฉันกำลังดูบทความC # - วัตถุการถ่ายโอนข้อมูลบน DTO ที่ต่อเนื่องกันได้

บทความประกอบด้วยรหัสชิ้นนี้:

public static string SerializeDTO(DTO dto) {
    try {
        XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
        StringWriter sWriter = new StringWriter();
        xmlSer.Serialize(sWriter, dto);
        return sWriter.ToString();
    }
    catch(Exception ex) {
        throw ex;
    }
}

ส่วนที่เหลือของบทความดูมีเหตุผลและสมเหตุสมผล (สำหรับ noob) แต่การลองจับการขว้างเป็น WtfException ... นี่มันไม่เทียบเท่ากับการจัดการกับข้อยกเว้นหรือเปล่า?

Ergo:

public static string SerializeDTO(DTO dto) {
    XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
    StringWriter sWriter = new StringWriter();
    xmlSer.Serialize(sWriter, dto);
    return sWriter.ToString();
}

หรือฉันขาดพื้นฐานบางอย่างเกี่ยวกับการจัดการข้อผิดพลาดใน C # มันค่อนข้างจะเหมือนกับ Java (ลบด้วยการตรวจสอบข้อยกเว้น) ใช่ไหม? ... นั่นคือพวกเขาทั้งสองได้ปรับปรุง C ++

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

แก้ไข:

เพียงเพื่อสรุปสำหรับทุกคนที่พบกระทู้นี้ในอนาคต ...

อย่า

try {
    // Do stuff that might throw an exception
}
catch (Exception e) {
    throw e; // This destroys the strack trace information!
}

ข้อมูลการติดตามสแต็กมีความสำคัญต่อการระบุสาเหตุของปัญหา!

ทำ

try {
    // Do stuff that might throw an exception
}
catch (SqlException e) {
    // Log it
    if (e.ErrorCode != NO_ROW_ERROR) { // filter out NoDataFound.
        // Do special cleanup, like maybe closing the "dirty" database connection.
        throw; // This preserves the stack trace
    }
}
catch (IOException e) {
    // Log it
    throw;
}
catch (Exception e) {
    // Log it
    throw new DAOException("Excrement occurred", e); // wrapped & chained exceptions (just like java).
}
finally {
    // Normal clean goes here (like closing open files).
}

ตรวจจับข้อยกเว้นเฉพาะเจาะจงมากขึ้นก่อนหน้าข้อ จำกัด ที่เฉพาะเจาะจงน้อยกว่า (เช่น Java)

อ้างอิง:

• MSDN - การจัดการข้อยกเว้น
• MSDN - ลองจับ (การอ้างอิง C #)

ครั้งแรก; วิธีที่รหัสในบทความมันเป็นความชั่วร้าย throw exจะรีเซ็ต call stack ในข้อยกเว้นเป็นจุดที่คำสั่ง throw นี้คือ; สูญเสียข้อมูลเกี่ยวกับข้อยกเว้นที่สร้างขึ้นจริง

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

อย่างไรก็ตามมีหลายกรณีที่คุณอาจต้องการตรวจจับและสร้างข้อยกเว้นขึ้นใหม่ การบันทึกอาจเป็นหนึ่งในนั้น:

try 
{
    // code that may throw exceptions    
}
catch(Exception ex) 
{
    // add error logging here
    throw;
}

อย่าทำอย่างนี้

try 
{
...
}
catch(Exception ex)
{
   throw ex;
}

คุณจะสูญเสียข้อมูลการติดตามสแต็ก ...

ทั้งทำ

try { ... }
catch { throw; }

หรือ

try { ... }
catch (Exception ex)
{
    throw new Exception("My Custom Error Message", ex);
}

หนึ่งในเหตุผลที่คุณอาจต้องการสร้างใหม่คือถ้าคุณจัดการข้อยกเว้นต่าง ๆ เช่น

try
{
   ...
}
catch(SQLException sex)
{
   //Do Custom Logging 
   //Don't throw exception - swallow it here
}
catch(OtherException oex)
{
   //Do something else
   throw new WrappedException("Other Exception occured");
}
catch
{
   System.Diagnostics.Debug.WriteLine("Eeep! an error, not to worry, will be handled higher up the call stack");
   throw; //Chuck everything else back up the stack
}

C # (ก่อนหน้า C # 6) ไม่สนับสนุน CIL "ตัวกรองข้อยกเว้น" ซึ่ง VB ทำดังนั้นใน C # 1-5 เหตุผลหนึ่งในการโยนข้อยกเว้นอีกครั้งคือคุณไม่มีข้อมูลเพียงพอในเวลาที่จับ () เพื่อตรวจสอบว่าคุณต้องการตรวจจับข้อยกเว้นจริงหรือไม่

ตัวอย่างเช่นใน VB คุณสามารถทำได้

Try
 ..
Catch Ex As MyException When Ex.ErrorCode = 123
 .. 
End Try

... ซึ่งจะไม่จัดการ MyExceptions ด้วยค่า ErrorCode ที่แตกต่างกัน ใน C # ก่อนหน้า v6 คุณจะต้องจับและโยน MyException อีกครั้งหาก ErrorCode ไม่ใช่ 123:

try 
{
   ...
}
catch(MyException ex)
{
    if (ex.ErrorCode != 123) throw;
    ...
}

ตั้งแต่ C # 6.0 คุณสามารถกรองเหมือนกับ VB:

try 
{
  // Do stuff
} 
catch (Exception e) when (e.ErrorCode == 123456) // filter
{
  // Handle, other exceptions will be left alone and bubble up
}

เหตุผลหลักของฉันที่มีรหัสเช่น:

try
{
    //Some code
}
catch (Exception e)
{
    throw;
}

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

พวกมันดีในระหว่างการดีบั๊ก

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

public static string SerializeDTO(DTO dto) {
  try {
      XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
      StringWriter sWriter = new StringWriter();
      xmlSer.Serialize(sWriter, dto);
      return sWriter.ToString();
  }
  catch(Exception ex) {
    string message = 
      String.Format("Something went wrong serializing DTO {0}", DTO);
    throw new MyLibraryException(message, ex);
  }
}

สิ่งนี้เทียบเท่ากับการไม่จัดการกับข้อยกเว้นทั้งหมดหรือไม่

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

คุณไม่ต้องการที่จะโยนอดีต - เช่นนี้จะสูญเสียการโทรสแต็ค ดูการจัดการข้อยกเว้น (MSDN)

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

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

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

ในภาษา. NET ส่วนใหญ่วิธีเดียวที่จะให้โค้ดดำเนินการตามข้อยกเว้นคือcatch(แม้ว่าจะรู้ว่ามันจะไม่สามารถแก้ไขข้อยกเว้นได้) ให้ดำเนินการกับปัญหาthrowตามที่ต้องการ อีกวิธีหนึ่งที่เป็นไปได้หากโค้ดไม่สนใจว่าข้อยกเว้นใดที่จะถูกโยนคือใช้okแฟล็กกับtry/finallyบล็อก ตั้งค่าokสถานะfalseก่อนหน้าบล็อกและtrueก่อนออกจากบล็อกและก่อนหน้าใด ๆreturnที่อยู่ภายในบล็อก จากนั้นภายในfinallyสมมติว่าหากokไม่ได้ตั้งค่าจะต้องมีข้อยกเว้นเกิดขึ้น วิธีการดังกล่าวดีกว่า a catch/ semantically throwแต่น่าเกลียดและบำรุงรักษาน้อยกว่าที่ควรจะเป็น

สิ่งนี้มีประโยชน์เมื่อฟังก์ชันการเขียนโปรแกรมของคุณสำหรับไลบรารีหรือ dll

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

ฉันคิดว่านี่ใช้เพียงเพื่อให้ข้อยกเว้นที่ถูกโยนนั้นสะอาดและไม่เข้าไปใน "ราก" ของห้องสมุด

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

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

คุณอาจพูดCatch io.FileNotFoundExeption exแล้วใช้เส้นทางของไฟล์ทางเลือกหรือบางอย่าง แต่ยังคงมีข้อผิดพลาด

นอกจากนี้การทำThrowแทนที่จะThrow Exช่วยให้คุณสามารถติดตามสแต็กเต็ม Throw ex รีสตาร์ทการติดตามสแต็กจากข้อความ Throw (ฉันหวังว่าเหมาะสม)

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

ตัวอย่างนี้เป็นที่ที่คุณมีวิธีการที่คุณตั้งค่าเคอร์เซอร์ (ตัวอย่างเช่นเคอร์เซอร์รอ) วิธีการมีหลายจุดทางออก (เช่นถ้า () กลับ;) และคุณต้องการให้แน่ใจว่าเคอร์เซอร์ถูกรีเซ็ตที่ สิ้นสุดของวิธีการ

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

try
{
    Cursor.Current = Cursors.WaitCursor;
    // Test something
    if (testResult) return;
    // Do something else
}
catch
{
    throw;
}
finally
{
     Cursor.Current = Cursors.Default;
}

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

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

ในการทำซ้ำอีกครั้งแม้ว่าจะไม่มีจุดในการตรวจจับข้อยกเว้นในตัวอย่างที่คุณโพสต์ อย่าทำอย่างนั้น!

ขออภัยตัวอย่างมากมายเช่น "การออกแบบที่ปรับปรุง" ยังคงมีกลิ่นอย่างน่ากลัวหรืออาจทำให้เข้าใจผิดอย่างยิ่ง ต้องลอง {} catch {log; การโยน} นั้นไร้สาระอย่างที่สุด การบันทึกข้อยกเว้นควรทำในตำแหน่งกึ่งกลางภายในแอปพลิเคชัน ข้อยกเว้นทำให้สแต็คของแทร็คเทรซทำไมไม่ลองบันทึกมันไว้ที่อื่นและใกล้กับขอบของระบบ?

ควรใช้ข้อควรระวังเมื่อคุณทำให้บริบทของคุณเป็นอนุกรม (เช่น DTO ในตัวอย่างหนึ่งที่กำหนด) เพียงลงในข้อความบันทึก มันสามารถมีข้อมูลที่ละเอียดอ่อนซึ่งอาจไม่ต้องการเข้าถึงมือของทุกคนที่สามารถเข้าถึงไฟล์บันทึกได้ และถ้าคุณไม่เพิ่มข้อมูลใหม่ลงในข้อยกเว้นฉันไม่เห็นจุดตัดข้อยกเว้นจริงๆ Java แบบเก่าที่ดีมีบางจุดที่ต้องการให้ผู้เรียกทราบว่ามีข้อยกเว้นประเภทใดที่ควรคาดหวังจากนั้นจึงเรียกใช้รหัส เนื่องจากคุณไม่มีสิ่งนี้ใน. NET การตัดคำไม่ได้ดีในกรณีอย่างน้อย 80% ที่ฉันเคยเห็น

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

คำตอบส่วนใหญ่พูดถึงสถานการณ์ catch-log-rethrow

แทนที่จะเขียนในรหัสของคุณให้พิจารณาใช้ AOP โดยเฉพาะPostsharp.Diagnostic.Toolkitด้วย OnExceptionOptions IncludeParameterValue และ IncludeThisArgument

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

ตัวอย่าง:

string numberText = "";
try
{
    Console.Write("Enter an integer: ");
    numberText = Console.ReadLine();
    var result = int.Parse(numberText);

    Console.WriteLine("You entered {0}", result);
}
catch (FormatException)
{
    if (numberText.ToLowerInvariant() == "nothing")
    {
        Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
    }
    else
    {
        throw;
    }
}    
finally
{
    Console.WriteLine("Freed some resources.");
}
Console.ReadKey();

อย่างไรก็ตามยังมีวิธีอื่นในการทำเช่นนี้โดยใช้คำสั่งแบบมีเงื่อนไขในบล็อก catch:

string numberText = "";
try
{
    Console.Write("Enter an integer: ");
    numberText = Console.ReadLine();
    var result = int.Parse(numberText);

    Console.WriteLine("You entered {0}", result);
}
catch (FormatException) when (numberText.ToLowerInvariant() == "nothing")
{
    Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
}    
finally
{
    Console.WriteLine("Freed some resources.");
}
Console.ReadKey();

กลไกนี้มีประสิทธิภาพมากกว่าการโยนข้อยกเว้นอีกครั้งเนื่องจากการรันไทม์. NET ไม่จำเป็นต้องสร้างวัตถุข้อยกเว้นก่อนที่จะทำการโยนอีกครั้ง