การทิ้ง RuntimeExceptions ใหม่ในโค้ดที่ไม่สามารถเข้าถึงได้เป็นสไตล์ที่ไม่ดีหรือไม่?

ฉันได้รับมอบหมายให้ดูแลรักษาแอปพลิเคชันที่เขียนเมื่อไม่นานมานี้โดยนักพัฒนาที่มีทักษะมากกว่า ฉันเจอโค้ดนี้แล้ว:

public Configuration retrieveUserMailConfiguration(Long id) throws MailException {
        try {
            return translate(mailManagementService.retrieveUserMailConfiguration(id));
        } catch (Exception e) {
            rethrow(e);
        }
        throw new RuntimeException("cannot reach here");
    }

ฉันอยากรู้ว่าการขว้างปาRuntimeException("cannot reach here")นั้นมีเหตุผลหรือไม่ ฉันอาจจะพลาดสิ่งที่เห็นได้ชัดว่ารู้ว่าโค้ดนี้มาจากเพื่อนร่วมงานที่มีประสบการณ์มากกว่า
แก้ไข: นี่คือร่างใหม่ที่บางคำตอบเรียก ฉันถือว่ามันไม่สำคัญในคำถามนี้

private void rethrow(Exception e) throws MailException {
        if (e instanceof InvalidDataException) {
            InvalidDataException ex = (InvalidDataException) e;
            rethrow(ex);
        }
        if (e instanceof EntityAlreadyExistsException) {
            EntityAlreadyExistsException ex = (EntityAlreadyExistsException) e;
            rethrow(ex);
        }
        if (e instanceof EntityNotFoundException) {
            EntityNotFoundException ex = (EntityNotFoundException) e;
            rethrow(ex);
        }
        if (e instanceof NoPermissionException) {
            NoPermissionException ex = (NoPermissionException) e;
            rethrow(ex);
        }
        if (e instanceof ServiceUnavailableException) {
            ServiceUnavailableException ex = (ServiceUnavailableException) e;
            rethrow(ex);
        }
        LOG.error("internal error, original exception", e);
        throw new MailUnexpectedException();
    }


private void rethrow(ServiceUnavailableException e) throws
            MailServiceUnavailableException {
        throw new MailServiceUnavailableException();
    }

private void rethrow(NoPermissionException e) throws PersonNotAuthorizedException {
    throw new PersonNotAuthorizedException();
}

private void rethrow(InvalidDataException e) throws
        MailInvalidIdException, MailLoginNotAvailableException,
        MailInvalidLoginException, MailInvalidPasswordException,
        MailInvalidEmailException {
    switch (e.getDetail()) {
        case ID_INVALID:
            throw new MailInvalidIdException();
        case LOGIN_INVALID:
            throw new MailInvalidLoginException();
        case LOGIN_NOT_ALLOWED:
            throw new MailLoginNotAvailableException();
        case PASSWORD_INVALID:
            throw new MailInvalidPasswordException();
        case EMAIL_INVALID:
            throw new MailInvalidEmailException();
    }
}

private void rethrow(EntityAlreadyExistsException e)
        throws MailLoginNotAvailableException, MailEmailAddressAlreadyForwardedToException {
    switch (e.getDetail()) {
        case LOGIN_ALREADY_TAKEN:
            throw new MailLoginNotAvailableException();
        case EMAIL_ADDRESS_ALREADY_FORWARDED_TO:
            throw new MailEmailAddressAlreadyForwardedToException();
    }
}

private void rethrow(EntityNotFoundException e) throws
        MailAccountNotCreatedException,
        MailAliasNotCreatedException {
    switch (e.getDetail()) {
        case ACCOUNT_NOT_FOUND:
            throw new MailAccountNotCreatedException();
        case ALIAS_NOT_FOUND:
            throw new MailAliasNotCreatedException();
    }
}

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

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

ข้อผิดพลาดคือค่า

^{(แปลกใจมันเป็นที่รู้จักกันดีในระหว่างการเดินทาง )}

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

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

private Exception logAndWrap(Exception exception) {
    // or whatever it actually does
    Log.e("Ouch! " + exception.getMessage());
    return new CustomWrapperException(exception);
}

จากนั้นคุณอธิบายthrowอย่างชัดเจนและผู้แปลมีความสุข:

try {
     return translate(mailManagementService.retrieveUserMailConfiguration(id));
} catch (Exception e) {
     throw logAndWrap(e);
}

เกิดอะไรขึ้นถ้าคุณลืมthrow?

ตามที่อธิบายไว้ในความคิดเห็น Joe23 ของการเขียนโปรแกรมการป้องกันวิธีการเพื่อให้มั่นใจว่าข้อยกเว้นจะโยนมักจะประกอบด้วยใน explicitely ทำthrow new CustomWrapperException(exception)ในตอนท้ายของlogAndWrapตามที่มันจะกระทำโดยGuava.Throwables ด้วยวิธีนี้คุณรู้ว่าข้อยกเว้นจะถูกโยนทิ้งและตัววิเคราะห์ชนิดของคุณมีความสุข อย่างไรก็ตามข้อยกเว้นที่กำหนดเองของคุณจำเป็นต้องถูกตรวจสอบข้อยกเว้นซึ่งเป็นไปไม่ได้เสมอไป นอกจากนี้ฉันจะให้คะแนนความเสี่ยงของนักพัฒนาซอฟต์แวร์ที่พลาดการเขียนthrowให้อยู่ในระดับต่ำมาก: ผู้พัฒนาต้องลืมและวิธีการโดยรอบไม่ควรส่งคืนสิ่งใด นี่เป็นวิธีที่น่าสนใจในการต่อสู้กับระบบการพิมพ์และใช้งานได้

rethrow

จริงrethrowสามารถเขียนเป็นฟังก์ชันด้วย แต่ฉันมีปัญหากับการใช้ปัจจุบัน:

• มีวรรณะไร้ประโยชน์มากมายเช่น อันที่จริงมันเป็นสิ่งจำเป็น (ดูความคิดเห็น):

  if (e instanceof ServiceUnavailableException) {
      ServiceUnavailableException ex = (ServiceUnavailableException) e;
      rethrow(ex);
  }

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

  private void rethrow(EntityAlreadyExistsException e)
      throws MailLoginNotAvailableException, MailEmailAddressAlreadyForwardedToException {
      switch (e.getDetail()) {
          case LOGIN_ALREADY_TAKEN:
              throw new MailLoginNotAvailableException();
          case EMAIL_ADDRESS_ALREADY_FORWARDED_TO:
              throw new MailEmailAddressAlreadyForwardedToException();
      }
  }

• ทำไมรหัสต้นทางไม่ส่งข้อยกเว้นพิเศษเหล่านั้นตั้งแต่แรก? ฉันสงสัยว่าrethrowใช้เป็นเลเยอร์ความเข้ากันได้ระหว่างระบบย่อย (การส่งเมล) และตรรกะธุรกิจ (อาจเจตนาคือซ่อนรายละเอียดการใช้งานเช่นข้อยกเว้นที่ส่งออกโดยแทนที่ด้วยข้อยกเว้นแบบกำหนดเอง) แม้ว่าฉันจะเห็นด้วยว่าจะเป็นการดีกว่าถ้ามีรหัสที่ดักฟังตามคำแนะนำในคำตอบของ Pete Beckerฉันไม่คิดว่าคุณจะมีโอกาสลบcatchและrethrowรหัสที่นี่ได้โดยไม่ต้องทำการปรับเปลี่ยนครั้งใหญ่

rethrow(e);ฟังก์ชั่นนี้ละเมิดหลักการที่ระบุว่าภายใต้สถานการณ์ปกติฟังก์ชั่นจะกลับมาในขณะที่ภายใต้สถานการณ์พิเศษฟังก์ชั่นจะโยนข้อยกเว้น ฟังก์ชั่นนี้ละเมิดหลักการนี้โดยการโยนข้อยกเว้นภายใต้สถานการณ์ปกติ นั่นคือที่มาของความสับสนทั้งหมด

คอมไพเลอร์สันนิษฐานว่าฟังก์ชั่นนี้จะกลับมาภายใต้สถานการณ์ปกติดังนั้นเท่าที่คอมไพเลอร์สามารถบอกได้การดำเนินการอาจถึงจุดสิ้นสุดของretrieveUserMailConfigurationฟังก์ชั่น ณ จุดนี้มันเป็นข้อผิดพลาดที่จะไม่มีreturnคำสั่ง ผู้RuntimeExceptionขว้างมีควรที่จะบรรเทาความกังวลของคอมไพเลอร์นี้ แต่มันเป็นวิธีที่ค่อนข้าง clunky ในการทำมัน อีกวิธีในการป้องกันfunction must return a valueข้อผิดพลาดคือการเพิ่มreturn null; //to keep the compiler happyคำสั่ง

ดังนั้นโดยส่วนตัวฉันจะแทนที่สิ่งนี้:

rethrow(e);

ด้วยสิ่งนี้:

report(e); 
throw e;

หรือดีกว่ายัง (ตามที่แนะนำ coredump ) กับสิ่งนี้:

throw reportAndTransform(e);

ดังนั้นการไหลของการควบคุมจะทำให้ชัดเจนกับคอมไพเลอร์ดังนั้นสุดท้ายของคุณ throw new RuntimeException("cannot reach here");จะไม่เพียง แต่ซ้ำซ้อน แต่จริงๆแล้วไม่ได้คอมไพล์เพราะมันจะถูกตั้งค่าสถานะโดยคอมไพเลอร์เป็นรหัสที่ไม่สามารถเข้าถึงได้

นั่นเป็นวิธีที่ดีที่สุดและง่ายที่สุดในการออกจากสถานการณ์ที่น่าเกลียดนี้

throwอาจจะเพิ่มการรับรอบ "วิธีการจะต้องส่งคืนค่า" ความผิดพลาดที่อาจจะเกิดขึ้น - ข้อมูล Java ไหลวิเคราะห์เป็นพอสมาร์ทที่จะเข้าใจว่าไม่มีreturnความจำเป็นหลังจากที่throwแต่ไม่ได้หลังจากที่คุณกำหนดrethrow()วิธีการและไม่มี@NoReturnคำอธิบายประกอบ ที่คุณสามารถใช้เพื่อแก้ไขปัญหานี้

อย่างไรก็ตามการสร้างข้อยกเว้นใหม่ในโค้ดที่ไม่สามารถเข้าถึงได้ดูเหมือนว่าไม่จำเป็น ฉันจะเขียนเพียงreturn nullรู้ว่ามันเป็นจริงไม่เคยเกิดขึ้น

The

throw new RuntimeException("cannot reach here");

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

อย่างไรก็ตามrethrow(e)ดูเหมือนผิด! ดังนั้นในกรณีของคุณฉันคิดว่าการเปลี่ยนรหัสเป็นตัวเลือกที่ดีกว่า ดูคำตอบอื่น ๆ (ฉันชอบที่สุดของ coredump) สำหรับวิธีจัดเรียงโค้ดของคุณ

ฉันไม่รู้ว่ามีการประชุมหรือไม่

อย่างไรก็ตามเคล็ดลับอื่นจะทำเช่นนั้น:

private <T> T rethrow(Exception exception) {
    // or whatever it actually does
    Log.e("Ouch! " + exception.getMessage());
    throw new CustomWrapperException(exception);
}

อนุญาตสำหรับสิ่งนี้:

try {
     return translate(mailManagementService.retrieveUserMailConfiguration(id));
} catch (Exception e) {
     return rethrow(e);
}

และไม่RuntimeExceptionจำเป็นต้องใช้สิ่งประดิษฐ์อีกต่อไป แม้ว่าจะrethrowไม่ได้คืนค่าใด ๆ แต่ก็ดีพอสำหรับคอมไพเลอร์แล้ว

มันส่งคืนค่าในทางทฤษฎี (วิธีการลงนาม) และจากนั้นก็จะได้รับการยกเว้นจากการทำเช่นนั้นเพราะมันจะโยนข้อยกเว้นแทน

ใช่มันอาจดูแปลก แต่แล้วอีกครั้ง - ขว้างปีศาจRuntimeExceptionหรือคืนโมฆะที่ไม่เคยเห็นในโลกนี้ - นั่นไม่ใช่เรื่องของความงาม

การดิ้นรนเพื่อความสามารถในการอ่านคุณสามารถเปลี่ยนชื่อrethrowและมีดังนี้:

} catch (Exception e) {
     return nothingJustRethrow(e);
}

หากคุณลบtryบล็อกสมบูรณ์แล้วคุณไม่จำเป็นต้องใช้หรือrethrow throwรหัสนี้ทำสิ่งเดียวกับของเดิม:

public Configuration retrieveUserMailConfiguration(Long id) throws MailException {
    return translate(mailManagementService.retrieveUserMailConfiguration(id));
}

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

แก้ไข: ฉันอ่านผิดrethrow(e)เพียงแค่โยนข้อยกเว้นอีกครั้งeอีกครั้ง หากrethrowวิธีการนั้นทำสิ่งอื่นที่ไม่ใช่การยกเว้นข้อผิดพลาดอีกครั้งการกำจัดมันจะเปลี่ยนซีแมนทิกส์ของวิธีการนี้