The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Иногда мы повторно выбрасываем исключения. В Java мы делаем это чаще, чем в других языках, потому что у нее есть проверяемые исключения. Иногда нам приходится перехватывать и повторно выбрасывать несколько исключений, возникших из разных мест в методе. В Java 7 была введена группировка разных типов исключений в одном блоке catch. Но даже без группировки можно просто перехватить IOException или даже Exception и предоставить один блок catch для всех типов и всех источников (методов, выбрасывающих исключения). Недавно я осознал, что это плохая практика. Вот почему.
Рассмотрим этот метод на Java (я использую Apache Commons IO):
Это не идеально. Давайте перепишем его, чтобы предоставить больше контекста ошибки, как было предложено ранее:
Здесь исключение может быть сгенерировано в трех местах:
По методу
openStream()Методом
toByteArray(https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/IOUtils.html#toByteArray-java.io.InputStream-)
Независимо от того, кто бросает, мы ловим это в одном и том же блоке catch и повторно бросаем с тем же сообщением. Я считаю, что это плохо, потому что контекст ошибки, предоставленный повторным броском, менее сфокусирован на возникшей проблеме.
Я бы предложил провести такое рефакторинг (я не закрываю входной поток, что неправильно, но это отдельная тема для обсуждения):
Этот код гораздо длиннее, но в то же время более удобен для отладки, тестирования и использования в режиме продукции. Блок catch способен лучше объяснить ситуацию и предоставить более точный контекст в перебрасываемом исключении, поскольку работает только с одним случаем.
Таким образом, правило, которое я предлагаю: если исключение перехватывается, каждый инициатор должен иметь свой собственный блок catch.
Очевидно, я считаю, что группировка типов исключений в одном блоке catch является плохой практикой.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 14:56
