ทำไมวิธีการไม่ควรโยนข้อยกเว้นที่ตรวจสอบหลายประเภท

เราใช้ SonarQube เพื่อวิเคราะห์โค้ด Java ของเราและมีกฎนี้ (ตั้งค่าเป็นวิกฤติ):

วิธีการสาธารณะควรมีข้อยกเว้นที่ตรวจสอบได้มากที่สุดหนึ่งรายการ

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

เพื่อรักษาความซับซ้อนสำหรับผู้โทรที่เหมาะสมวิธีการไม่ควรมีข้อยกเว้นที่ตรวจสอบมากกว่าหนึ่งประเภท "

อีกเล็กน้อยใน Sonar มีสิ่งนี้ :

วิธีการสาธารณะควรมีข้อยกเว้นที่ตรวจสอบได้มากที่สุดหนึ่งรายการ

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

เพื่อรักษาความซับซ้อนสำหรับผู้โทรที่เหมาะสมวิธีการไม่ควรมีข้อยกเว้นที่ตรวจสอบมากกว่าหนึ่งประเภท

รหัสต่อไปนี้:

public void delete() throws IOException, SQLException {      // Non-Compliant
  /* ... */
}

ควรได้รับการปรับสภาพใหม่เป็น:

public void delete() throws SomeApplicationLevelException {  // Compliant
    /* ... */
}

วิธีการแทนที่จะไม่ตรวจสอบโดยกฎนี้และได้รับอนุญาตให้โยนข้อยกเว้นที่ตรวจสอบหลายรายการ

ฉันไม่เคยเจอกฎนี้ / คำแนะนำในการอ่านของฉันเกี่ยวกับการจัดการข้อยกเว้นและได้พยายามหามาตรฐานการสนทนา ฯลฯ ในหัวข้อ สิ่งเดียวที่ฉันได้พบคือจาก CodeRach: วิธีการที่ควรยกเว้นมากที่สุด

นี่เป็นมาตรฐานที่ได้รับการยอมรับหรือไม่?

ให้พิจารณาสถานการณ์ที่คุณมีรหัสที่ให้:

public void delete() throws IOException, SQLException {      // Non-Compliant
  /* ... */
}

อันตรายที่นี่คือรหัสที่คุณเขียนเพื่อโทรdelete()จะมีลักษณะดังนี้:

try {
  foo.delete()
} catch (Exception e) {
  /* ... */
}

มันก็ไม่ดีเหมือนกัน และจะถูกจับด้วยกฎอื่นที่จับค่าสถานะการยกเว้นคลาสพื้นฐาน

กุญแจสำคัญคือการไม่เขียนโค้ดที่ทำให้คุณต้องการเขียนโค้ดไม่ดีที่อื่น

กฎที่คุณพบเป็นกฎที่ค่อนข้างใช้กันทั่วไป Checkstyleมีกฎการออกแบบ:

ThrowsCount

จำกัด การโยนข้อความสั่งให้นับที่ระบุ (1 โดยค่าเริ่มต้น)

เหตุผล: ข้อยกเว้นเป็นส่วนหนึ่งของส่วนต่อประสานของวิธีการ การประกาศวิธีการโยนข้อยกเว้นที่รูทแตกต่างกันมากเกินไปทำให้เกิดข้อยกเว้นในการจัดการที่ยากลำบากและนำไปสู่แนวทางการเขียนโปรแกรมที่ไม่ดีเช่นการเขียนโค้ดเช่น catch (Exception ex) การตรวจสอบนี้บังคับให้นักพัฒนาวางข้อยกเว้นลงในลำดับชั้นซึ่งในกรณีที่ง่ายที่สุดผู้เรียกต้องตรวจสอบข้อยกเว้นเพียงประเภทเดียว แต่ผู้เรียนสามารถจับคลาสย่อยใด ๆ ได้หากจำเป็น

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

และในขณะที่คุณอาจทำตามการออกแบบภาษาและอาจมีบางครั้งที่มันเป็นสิ่งที่ถูกต้องที่จะทำมันเป็นสิ่งที่คุณควรเห็นและไปทันที "อืมทำไมฉันถึงทำอย่างนี้?" อาจเป็นที่ยอมรับได้สำหรับรหัสภายในที่ทุกคนได้รับการลงโทษทางวินัยมากพอที่จะไม่ทำcatch (Exception e) {}แต่บ่อยครั้งที่ฉันไม่เห็นคนถูกตัดมุมโดยเฉพาะในสถานการณ์ภายใน

อย่าทำให้คนที่ใช้คลาสของคุณต้องการเขียนโค้ดที่ไม่ดี

ฉันควรชี้ให้เห็นว่าความสำคัญของสิ่งนี้ลดลงด้วย Java SE 7 และหลังจากนั้นเนื่องจากคำสั่ง catch เดี่ยวสามารถตรวจจับข้อยกเว้นหลาย ๆ ข้อได้ (การตรวจจับชนิดข้อยกเว้นหลายรายการและข้อยกเว้น Rethrowing ด้วยการปรับปรุงการตรวจสอบประเภทจาก Oracle)

ด้วย Java 6 และก่อนหน้านี้คุณจะมีโค้ดที่ดูเหมือน:

public void delete() throws IOException, SQLException {
  /* ... */
}

และ

try {
  foo.delete()
} catch (IOException ex) {
     logger.log(ex);
     throw ex;
} catch (SQLException ex) {
     logger.log(ex);
     throw ex;
}

หรือ

try {
    foo.delete()
} catch (Exception ex) {
    logger.log(ex);
    throw ex;
}

ตัวเลือกเหล่านี้กับ Java 6 ไม่เหมาะอย่างยิ่ง วิธีแรกละเมิดแห้ง บล็อกจำนวนมากทำสิ่งเดียวกันซ้ำแล้วซ้ำอีก - ครั้งเดียวสำหรับแต่ละข้อยกเว้น คุณต้องการที่จะเข้าสู่ระบบข้อยกเว้นและ rethrow มันได้หรือไม่ ตกลง. บรรทัดของรหัสเดียวกันสำหรับแต่ละข้อยกเว้น

ตัวเลือกที่สองนั้นแย่กว่าด้วยเหตุผลหลายประการ ครั้งแรกมันหมายความว่าคุณกำลังจับข้อยกเว้นทั้งหมด ตัวชี้ Null ติดอยู่ที่นั่น (และไม่ควร) นอกจากนี้คุณจะ rethrowing Exceptionซึ่งหมายความว่าลายเซ็นวิธีจะเป็นdeleteSomething() throws Exceptionซึ่งก็ทำให้เป็นระเบียบเพิ่มเติมขึ้นสแต็คเป็นคนที่ใช้รหัสของคุณตอนนี้บังคับให้catch(Exception e)ไป

ด้วย Java 7 สิ่งนี้ไม่สำคัญเท่ากับคุณทำได้:

catch (IOException|SQLException ex) {
    logger.log(ex);
    throw ex;
}

นอกจากนี้ประเภทการตรวจสอบถ้าไม่จับประเภทของข้อยกเว้นที่ถูกโยน:

public void rethrowException(String exceptionName)
throws IOException, SQLException {
    try {
        foo.delete();
    } catch (Exception e) {
        throw e;
    }
}

ตัวตรวจสอบชนิดจะรู้ว่าeอาจเพียง แต่จะเป็นประเภทหรือIOException SQLExceptionฉันยังคงไม่กระตือรือร้นมากเกินไปเกี่ยวกับการใช้งานสไตล์นี้ แต่มันไม่ได้ทำให้เกิดรหัสที่ไม่ดีอย่างที่มันเป็นภายใต้ Java 6 (ซึ่งมันจะบังคับให้คุณมีลายเซ็นวิธีการเป็น superclass ที่ข้อยกเว้นขยาย)

แม้จะมีการเปลี่ยนแปลงเหล่านี้ แต่เครื่องมือการวิเคราะห์แบบสแตติกจำนวนมาก (Sonar, PMD, Checkstyle) ยังคงบังคับใช้คำแนะนำสไตล์ Java 6 มันไม่ใช่เรื่องเลวร้าย ฉันมักจะเห็นด้วยกับคำเตือนเหล่านี้ว่าจะยังคงมีการบังคับใช้ แต่คุณอาจเปลี่ยนลำดับความสำคัญเป็นหลักหรือรองตามวิธีที่ทีมของคุณจัดลำดับความสำคัญ

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

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

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

public String getData(int id) throws FileNotFoundException

ตอนนี้เรามีการเปลี่ยนแปลงข้อกำหนดและข้อมูลของเรามาจากฐานข้อมูล แทนที่จะเป็นFileNotFoundException(เนื่องจากเราไม่ได้เกี่ยวข้องกับไฟล์) ตอนนี้เราโยนSQLException:

public String getData(int id) throws SQLException

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

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

public String getData(int id) throws InvalidRecordException

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

สำหรับความรับผิดชอบเดี่ยวเราต้องคิดถึงรหัสที่ส่งข้อยกเว้นหลายอย่างที่ไม่เกี่ยวข้อง สมมติว่าเรามีวิธีการดังต่อไปนี้:

public Record parseFile(String filename) throws IOException, ParseException

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

public String readFile(String filename) throws IOException
public Record parse(String data) throws ParseException

เราแยกความรับผิดชอบในการอ่านไฟล์จากความรับผิดชอบในการแยกวิเคราะห์ข้อมูล ผลข้างเคียงของสิ่งนี้คือตอนนี้เราสามารถส่งผ่านข้อมูล String ใด ๆ ไปยังข้อมูลแยกวิเคราะห์จากแหล่งใด ๆ : ในหน่วยความจำ, ไฟล์, เครือข่าย, ฯลฯ เราสามารถทดสอบparseได้ง่ายขึ้นในตอนนี้เพราะเราไม่ต้องการไฟล์บนดิสก์ เพื่อทำการทดสอบ

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

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

http://tutorials.jenkov.com/java-exception-handling/checked-or-unchecked-exceptions.html

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

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

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

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

การขว้างข้อยกเว้นที่ตรวจสอบหลายข้อนั้นสมเหตุสมผลเมื่อมีหลายสิ่งที่ควรทำ

ตัวอย่างเช่นสมมติว่าคุณมีวิธีการ

public void doSomething(Credentials cred, Work work) 
    throws CredentialsRequiredException, TryAgainLaterException{...}

สิ่งนี้ละเมิดกฎข้อยกเว้น pne แต่สมเหตุสมผล

น่าเสียดายที่สิ่งที่เรามักจะเกิดขึ้นคือวิธีการต่างๆ

void doSomething() 
    throws IOException, JAXBException,SQLException,MyException {...}

ที่นี่มีโอกาสเล็กน้อยที่ผู้โทรจะทำสิ่งที่เฉพาะเจาะจงตามประเภทของข้อยกเว้น ดังนั้นหากเราต้องการที่จะเขยิบเขาให้ตระหนักว่าวิธีการเหล่านี้สามารถและบางครั้งจะผิดพลาดเพียงแค่ SomethingMightGoWrongException นั้นเป็น enogh และดีกว่า

ดังนั้นจึงต้องมีกฎที่ตรวจสอบได้มากที่สุดหนึ่งข้อยกเว้น

แต่ถ้าโครงการของคุณใช้การออกแบบที่มีหลายข้อยกเว้นการตรวจสอบความหมายเต็มกฎนี้ไม่ควรใช้

Sidenote: มีบางอย่างผิดพลาดจริง ๆ เกือบทุกที่ดังนั้นใครจะคิดถึงการใช้งานบ้าง ขยาย RuntimeException แต่มีความแตกต่างระหว่าง "เราทุกคนทำผิดพลาด" และ "นี่พูดถึงระบบภายนอกและบางครั้งมันจะลงจัดการกับมัน"