Является ли создание новых исключений RuntimeException в недоступном коде плохим стилем?

Мне поручили поддерживать приложение, написанное некоторое время назад более опытными разработчиками. Я наткнулся на этот кусок кода:

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")оправдан. Я, вероятно, упускаю что-то очевидное, зная, что этот кусок кода исходит от более опытного коллеги.
РЕДАКТИРОВАТЬ: Вот тело rethrow, что некоторые ответы упоминаются. Я посчитал это не важным в этом вопросе.

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 , способ защитного программирования , гарантирующий, что исключение всегда генерируется, состоит в том, чтобы явно делать a 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он используется как слой совместимости между (почтовой) подсистемой и логикой бизнес-процессов (возможно, цель состоит в том, чтобы скрыть детали реализации, такие как выданные исключения, заменив их пользовательскими исключениями). Даже если я согласен , что было бы лучше , чтобы поймать свободный код, как это было предложено в ответе Пит Беккером , я не думаю , что вы будете иметь возможность , чтобы удалить 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));
}

Не позволяйте тому факту, что это исходит от более опытных разработчиков, обмануть вас. Это код гнили, и это происходит постоянно. Просто исправь это.

РЕДАКТИРОВАТЬ: я неправильно прочитал rethrow(e)просто повторное исключение e. Если этот rethrowметод на самом деле делает что-то иное, чем перебрасывание исключения, то избавление от него меняет семантику этого метода.