Try-catch: это приемлемая практика?

Мы получили код Java от поставщика программного обеспечения. Он содержит много блоков try-catch, в которых нет ничего в части catch. Они повсюду. Пример:

        try {
            spaceBlock.enable(LindsayModel);
        } catch (Exception e) {
        }

Мои вопросы: Является ли вышеуказанная приемлемая практика? Если да, то когда? Или я должен просто пойти и удалить все эти "фиктивные" try и catch заявления?

Для меня это выглядит как ужасная практика, но я недостаточно опытна в Java, чтобы точно сказать. Зачем ловить ошибки, если вы ничего не собираетесь с ними делать? Мне кажется, вы только сделали бы это, если бы были уверены, что исключение не будет иметь абсолютно никакого значения, и вам все равно, если это произойдет. Однако в нашем конкретном приложении это не совсем так.

РЕДАКТИРОВАТЬ. Чтобы дать некоторый контекст: мы купили Java-скриптовый продукт от поставщика. Наряду с продуктом они предоставили большое доказательство концепции script, соответствующее нашим потребностям. Этот script стал "бесплатным" (хотя мы бы не купили продукт, если он не пришел с script), и он "работает". Но script - настоящая боль, на которую можно опираться, из-за многих вещей, которые даже я, как начинающий Java, признаю как ужасную практику, одним из примеров является этот фиктивный бизнес try-catch.

ОТВЕТЫ

Ответ 1

Это действительно ужасная практика. Особенно улавливание Exception, а не что-то конкретное, выдает ужасный запах - даже a NullPointerException будет проглочен. Даже если он уверен, что конкретное исключенное исключение не имеет никакого реального значения, всегда нужно записывать его как минимум:

try {
    // code
}
catch (MyInconsequentialException mie) {
   // tune level for this logger in logging config file if this is too spammy
   MY_LOGGER.warning("Caught an inconsequential exception.", mie);
}

Однако маловероятно, что в этой ситуации исключение совершенно бессмысленно. Я рекомендую исследовать, какие именно исключения (-ы) код приложения намеревается усвоить здесь, и что они действительно означают для выполнения.

Одно важное различие заключается в том, используются ли попытки/уловы для проглатывания проверенных исключений. Если это так, это, вероятно, указывает на чрезвычайную апатию к части программиста - кто-то просто хотел, чтобы его/ее код компилировался. По крайней мере, код должен быть изменен:

try {
   // code
}
catch (SpecificCheckedException sce) {
   // make sure there is exception logging done farther up
   throw new RuntimeException(sce);
}

Это уменьшит исключение, завернутое в unchecked RuntimeException, эффективно разрешая компиляцию кода. Однако даже это можно рассматривать как бандаду, но лучше всего проверять исключения - обрабатывать их на индивидуальной основе либо в текущем методе, либо дальше, добавляя throws SpecificCheckedException к сигнатуре метода.

Как упоминалось @Tom Hawtin, new Error(sce) можно использовать вместо new RuntimeException(sce), чтобы обойти любые дополнительные Exception уловы дальше, что имеет смысл для чего-то, чего нельзя ожидать.

Если try/catch не используется для проглатывания проверенных исключений, он одинаково опасен и должен быть просто удален.

Ответ 2

Ужасно, действительно. Проглатывание такого исключения может быть опасным. Как вы узнаете, произошло ли что-то плохое?

Мне было бы лучше, если бы продавец написал комментарии к документу и подтвердил его ( "Мы знаем, что делаем" ). Я бы чувствовал себя еще лучше, если бы в коде появилась стратегия, чтобы справиться с последствиями. Оберните его в RuntimeException и rethrow; установите для возвращаемого значения соответствующее значение. Что-нибудь!

"По всему месту"? Есть ли несколько блоков try/catch, засоряющих код? Лично мне не нравится эта идиома. Я предпочитаю один за метод.

Возможно, вам стоит найти нового поставщика или написать свой собственный.

Ответ 3

    try {
        meshContinuum.enable(MeshingModel);
    } catch (Exception e) {
    }

Это выглядит как незавершенный код. Если метод enable генерирует исключение, то он будет пойман и проглочен кодом. Если это не так, то не имеет смысла пытаться поймать незанятое исключение.

Отметьте, чтобы увидеть методы и где их подписи не следуют throws exceptionName, затем удалите пустые утверждения try-catch из тех мест, которые они вызывают.

Теоретически вы можете поставить try-catch вокруг любого оператора. Компилятор не будет жаловаться на это. Это не имеет смысла, так как таким образом можно скрыть настоящие исключения.

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

Ответ 4

Это не самое лучшее:

  • Он скрывает доказательства исключения, поэтому отладка сложнее

  • Это может привести к сбоям в работе функций

  • Это говорит о том, что автор, возможно, действительно хотел обработать исключение, но никогда не обходил его

Итак, могут быть случаи, когда это нормально, например исключение, которое действительно не имеет никакого значения (случай, который приходит в голову, это Python mkdirs, который генерирует исключение, если каталог уже существует), но обычно, это не так здорово.

Ответ 5

К сожалению, вы не можете просто удалить его, потому что блок try выбрал исключенное исключение, и оно должно быть объявлено в предложении throws метода. Затем вызывающим лицам метода будет catch он (но не если вызывающие лица также имеют эту catch (Exception e) {} мерзость).

В качестве альтернативы рассмотрим замену его на

try {
    meshContinuum.enable(MeshingModel);
} catch (Exception e) {
    throw (e instanceof RuntimeException) ? (RuntimeException) e : new RuntimeException(e);
}

Так как RuntimeException (и классы, которые его расширяют), это unchecked исключения, которые они не должны быть объявлены в предложении throws.

Ответ 6

Что указал ваш контракт с поставщиком? Если то, что они написали, плохая практика и все, соответствует спецификации, то они будут взимать плату за переписывание.

Лучше указать набор тестов, которые будут вводить многие или все эти блоки try-catch и, следовательно, терпят неудачу. Если тесты терпят неудачу, у вас есть лучший аргумент, чтобы заставить их исправить свой ужасный код.

Ответ 7

Ужасная идея на первый взгляд полностью зависит от того, что вы на самом деле называете. Обычно это делается из лени или привыкания к плохой практике.