Есть ли веская причина игнорировать пойманное исключение?

Question

Ничего себе, я только что получил огромный проект на C # от сторонних разработчиков, и, просматривая мой код, мой инструмент анализа обнаружил кучу того, что он считал плохим. Одно из самых обескураживающих сообщений было:

Exceptions.DontSwallowErrorsCatchingNonspecificExceptionsRule  : 2106 defects 

Разработчики уверяют меня, что у них есть веская причина для всех пустых блоков catch, что иногда попытка с пустыми блоками catch просто игнорирует бесполезные исключения и предотвращает сбой приложения. Я чувствую, что это полицейский и полный BS. Некоторые из примеров, которые я на самом деле искал, были вызовы базы данных, где запись была сохранена в базе данных, и в этом случае, если исключение было проигнорировано, пользователь вернул бы нормальное приглашение, подумал, что все в порядке, и продолжил их работа. На самом деле их работа никогда не была сохранена. Я думаю, что это абсолютно самая ужасная ошибка. В этом случае, они совершенно не правы, бросая этот код в попытке с пустым блоком catch. Но мой вопрос: "Это когда-либо приемлемо в ЛЮБОЙ ситуации?" Я думаю, что нет, но я, как известно, был неправ.

Answer 1

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

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

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

Answer 2

Да, это приемлемо (неизбежно, необходимо) в определенных обстоятельствах для поста Максима. Это не значит, что вам должно это нравиться. 2106 нарушений, вероятно, слишком много, и, по крайней мере, они должны были добавить комментарий в блоке catch о том, почему было нормально проглотить это исключение.

@ Dustin Это плохая практика - показывать подробности любых исключений общедоступному пользователю (следы стека, номера строк и т. Д.). Вам, вероятно, следует зарегистрировать исключение и отобразить общую ошибку.

Answer 3

Когда речь идет об исключениях, всегда есть исключения .

Answer 4

Это зависит от рамок. Плохо реализованные фреймворки могут действительно требовать этого. Я вспоминаю хак в VB6, где не было способа определить, содержит ли коллекция элемент. Единственным способом было попытаться получить элемент и проглотить ошибку.

Answer 5

Если ваш код улова не будет

1. Записать исключение
2. Упакуйте исключение в другое исключение, которое соответствует той же абстракции. и брось снова
3. Обрабатывает исключение так, как вы считаете подходящим

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

Answer 6

Мне очень интересно об этом конкретном.

Connection con = DriverManager.getConnection(url, "***", "***");

try {
    PreparedStatement pStmt = con.prepareStatement("your query here");

    ... // query the database and get the results
}
catch(ClassNotFoundException cnfe) {
    // real exception handling goes here
}
catch(SQLException sqle) {
    // real exception handling goes here
}
finally {
    try {
        con.close();
    }
    catch {
        // What do you do here?
    }
}

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

Answer 7

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

Может существовать вероятность того, что его можно будет отправить на доработку, что платеж будет частично удержан или что та же фирма не будет использоваться снова. Если ваша компания снова использует подрядчиков, они могут найти способ встроить требования по качеству в соглашения, при условии, что это не является проблемой.

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

Просто будьте осторожны, чтобы объяснить свою позицию профессионально и сосредоточиться на том, что лучше для компании / продукта. Вы не хотите, чтобы казалось, что вы просто жалуетесь или что у вас есть какое-то политическое возражение против аутсорсинга. Не думай о себе. Учитывайте стоимость, время выхода на рынок, удовлетворенность клиентов и т. Д. Вы знаете, все, что заботится о типах управления.

Answer 8

Для примера из мира Java, где нормально игнорировать исключение:

String foo="foobar";
byte[] foobytes;

try
{
    foobytes=foo.getBytes("UTF-8");
}
catch (UnsupportedEncodingException uee)
{
    // This is guaranteed by the Java Language Specification not to occur, 
    // since every Java implementation is required to support UTF-8.
}

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

...
catch (UnsupportedEncodingException uee)
{
    // This is guaranteed by the Java Language Specification not to occur, 
    // since every Java implementation is required to support UTF-8.
    uee.printStackTrace();
}

Если виртуальная машина будет сумасшедшей / ломающей спецификацию, я мало что могу с этим поделать, но с трассировкой стека я, по крайней мере, замечу, когда она начнет сходить с ума ...

Answer 9

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

Answer 10

Это действительно плохая вещь.

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

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