Чи кидання нових 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блоку. Ви можете повторно змінити код, скориставшись тим, що ...

Помилки - значення

^{(Не дивно, що це добре відомо в дорозі )}

Давайте скористаємося більш простим прикладом, який я використовував перед вашою редагуванням: тому уявіть, що ви щось записуєте та створюєте виняток для обгортки, як у відповіді Конрада . Давайте назвемо це 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 , захисний спосіб програмування для того, щоб завжди викидати виняток, полягав би в тому, що явно робимо в throw new CustomWrapperException(exception)кінці logAndWrap, як це робиться Guava.Throwables . Таким чином, ви знаєте, що виняток буде кинутий, і ваш аналізатор типу задоволений. Однак ваші власні винятки мають бути вивіреними винятками, що не завжди можливо. Крім того, я б оцінив ризик, який програвач не вистачає, щоб написати throwдуже низьким: розробник повинен забути це а навколишній метод нічого не повинен повертати, інакше компілятор виявить відсутність повернення. Це цікавий спосіб боротьби з типовою системою, і вона працює.

Ретроу

Фактичний також 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використовується як шар сумісності між підсистемою (розсилка) та логікою Busineess (можливо, наміром є приховати деталі реалізації, як викинуті винятки, замінивши їх на власні винятки). Навіть якщо я погоджуюся, що було б краще мати код без лову, як це запропоновано у відповіді Піта Беккера , я не думаю, що у вас не буде можливості видалити тут catchі rethrowкод без великих рефакторинга.

Ця rethrow(e);функція порушує принцип, який говорить про те, що за звичайних обставин функція повернеться, тоді як за виняткових обставин функція кине виняток. Ця функція порушує цей принцип, кидаючи виняток за звичайних обставин. Це джерело всієї плутанини.

Компілятор припускає, що ця функція повернеться за звичайних обставин, тому, наскільки компілятор може сказати, виконання може дійти до кінця retrieveUserMailConfigurationфункції, і тоді помилка не має returnзаяви. RuntimeException, Кинутих там , як передбачається , щоб полегшити цю проблему компілятора, але це досить незграбний спосіб зробити це. Ще один спосіб запобігання 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");

заява дає зрозуміти ОСОБІ, що читає код, що відбувається, тому набагато краще, ніж повернути нуль, наприклад. Це також спрощує налагодження, якщо код буде змінено несподівано.

Однак 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));
}

Не дозволяйте обдурити те, що це надходить від більш досвідчених розробників. Це кодова гниль, і вона відбувається постійно. Просто виправте це.

EDIT: Я неправильно читаю rethrow(e)як просто перекидання винятку e. Якщо цей rethrowметод насправді робить щось інше, ніж повторно викидати виняток, то позбавлення від нього змінює семантику цього методу.