Есть ли любая допустимая причина когда-либо проигнорировать перехваченную исключительную ситуацию

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

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

IMO легче знать разветвления в Java, так как каждый метод требуется, чтобы объявлять все исключения, которые это может выдать так, Вы знаете, что ожидать, но в C# может быть выдано исключение, даже если это не документируется, таким образом, трудно знать все возможные исключения, которые могут быть выданы методом и недостатком, что знание это обычно - плохая идея поймать все.

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

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

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

Следующий только относится к языкам, которые имеют контролируемые исключительные ситуации, например, Java:

Иногда метод бросает контролируемую исключительную ситуацию, которую Вы знаете , не произойдет, например, некоторые API Java ожидают имя кодирования как строку и бросают UnsupportedEncodingException, если данное кодирование не будет поддерживаться. Но обычно я передаю литеральный "UTF-8", который я знаю, поддерживается так, я мог теоретически записать пустую выгоду там.

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

Для взятия примера от мира 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();
}

, Если виртуальная машина будет быть mad/spec-breaking, существует мало, я могу делать с этим, но с отслеживанием стека, я, по крайней мере, добираюсь для замечания, когда это запустило свой спуск в безумие...

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

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

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

Интересно об этом определенном много.

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?
    }
}

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

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

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

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

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

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

Когда дело доходит до Исключений всегда существуют исключения .

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

    public FileStream OpenFile(string path)
    {
        FileStream f = null;
        try
        {
            f = new FileStream(path, FileMode.Open, FileAccess.ReadWrite);
        }
        catch (FileNotFoundException)
        {
        }
        return f;
    }

Вы могли также записать методу этот путь:

    public FileStream OpenFile(string path)
    {
        FileStream f = null;
        FileInfo fi = new FileInfo(path);
        if (fi.Exists)
        {
            f = new FileStream(path, FileMode.Open, FileAccess.ReadWrite);                
        }
        return f;
    }

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

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

, Но это игнорирует конкретный исключение. Этот код:

catch
{
}

непростительно.

нет никакого серьезного основания не поймать определенное введенное исключение, которое код в try блок собирается выдать. Первой причиной, что наивный разработчик дает для ловли исключений независимо от типа, "Но я не знаю, какое исключение могло бы быть выдано", является вид ответа на вопрос.

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

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

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

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

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

Я предполагаю, из какого я собираюсь, лучший ответ - то, что это может быть несколько приемлемо, но должно быть ограничено. Необходимо попытаться использовать другую альтернативу, и если Вы не можете найти другую альтернативу, необходимо знать достаточно о том, как работы кода, что можно ожидать определенные типы исключительной ситуации и не только использовать общую выгоду все "Исключение". Документация причины, почему это исключение проигнорировано, должна быть включена в форме понятного комментария.

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

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

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

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

кроме того, Вы не хотели бы делать его универсальной "выгодой (Исключение e) {}".

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

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

public void testSomething(){
    try{
        fooThatThrowsAnException(parameterThatCausesTheException);
        fail("The method didn't throw the exception that we expected it to");
    } catch(SomeException e){
        // do nothing, as we would expect this to happen, if the code works OK.
    }
}

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

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

@Test(expected = SomeException.class)
public void testSomething(){
    fooThatThrowsAnException(parameterThatCausesTheException);
    fail("The method didn't throw the exception that we expected it to");
}

Обычно не, на самом деле не в 99% всех случаев, НО

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

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

Я не ловлю исключения, если я не планирую сделать что-то о них. Игнорирование их не делает чего-то о них.

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

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

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

Да, его приемлемое (неизбежный, необходимый) при определенных обстоятельствах на сообщение Maxim's. Это не означает, что необходимо понравиться он. 2 106 нарушений - вероятно, Слишком многие, и самое меньшее они должны были добавить комментарий в блоке выгоды относительно того, почему было нормально глотать это исключение.

@Dustin Его плохая практика для показа любого исключения назначает в общедоступного пользователя (отслеживания стека, номера строки, и т.д.). Необходимо, вероятно, зарегистрировать исключение и отобразить универсальную ошибку.

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

Однако я действительно регистрирую ошибку. Я просто не повторно бросаю его.