Почему я должен написать все Заявления в Try-Catch?


12

Глава моей компании говорит, что я должен написать все, то есть ВСЕ свой код в инструкциях Try-catch. Теперь я могу понять подход «лучше быть безопасным, чем сожалеть», но разве не слишком утомительно думать, что при создании меток будет исключение, позиция формы установлена. Были ли случаи, когда исключения в таких простых операциях.


4
Это звучит как " жужжание" тех же людей, которые говорят, что весь SQL должен быть написан как хранимые процедуры для повышения производительности.
Спонг

5
Вы бы предпочли: «Если ваш код создает ошибку времени выполнения, вы уволены». Игра в курицу интересна до тех пор, пока вы не увидите, как ваш противник бросает руль и педаль тормоза в окно.
JeffO

4
@Джефф О - Я действительно считаю, что в разработке программного обеспечения противник - это грузовой поезд.
Йорис Тиммерманс

5
Лучшее выражение, которое я слышал для этого стиля обработки исключений, - это «пригвоздить труп в вертикальном положении», то есть приложение оставляет приложение в неожиданном состоянии. Fail Fast, Fail Loudly - гораздо более современный подход, так что вы можете устранить все ошибки.
Брук

2
Тема запроса не имеет значения ... просто сказать "глава моей компании говорит, что я должен кодировать ..." - это большой красный флаг. Это микроуправление ... это не его работа.
JoelFan

Ответы:


14

Глава моей компании говорит, что я должен написать все, то есть ВСЕ свой код в инструкциях Try-catch.

Ну, это немного преувеличено и просто приводит к шумному коду. Каковы преимущества написания всего кода (например, каждого метода) с помощью обработчика try catch? Он просто говорит вам, что в большинстве случаев нужно исправить ошибку. Часто исключение можно и нужно избегать в первую очередь.

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

Обработка исключений действительно довольно проста:

Поймать исключения

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

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

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

Не забывайте рано падать, когда дела идут (неустранимо) неправильно. Вводить весь код в операторы try-catch абсурдно, но не забывайте сообщать и регистрировать ВСЕ исключения.


+1 Это приводит не только к шумному коду, но и к худшей производительности. Когда вы помещаете операторы в блок try, компилятор HotSpot не сможет применить оптимизацию, которую он иначе сделал бы.
Оливер Вейлер

@ Оливер Вейлер: Есть ли у вас цитата, объясняющая, какие оптимизации не выполняет компилятор HotSpot в блоках try / catch?
Кайпро II

16

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

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

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


13
Мои приложения знают лучше, чем выбрасывать исключения, иначе они получат биения своей жизни. Как только они подумают, что ты с разбитым сердцем, они обрушатся на тебя.
JeffO

@ Майкл Боргвардт: хе-хе, так что вы меня опровергли. Вы отрицали по этому вопросу, и единственное отрицательное на мой пост. Похоже, у вас серьезные проблемы с эго или самооценкой. Я заметил это и в других вопросах. Знаете, у других программистов тоже есть хорошие ответы.
Сокол

@Falcon: я ничего не понизил по этому вопросу. Я понятия не имею, что заставляет вас верить в обратное, но если у кого-то есть серьезная проблема с эго, то это вы.
Майкл Боргвардт

@ Майкл Борвардт: Может быть, я ошибаюсь. В таком случае я прошу прощения. Может быть, это просто отрицательный ответ на ваш собственный вопрос, который заставил меня думать, что вы проголосовали здесь. Сожалею.
Сокол

8

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

Если вы не можете быть на 100% уверены, что сможете обработать каждое исключение, которое может быть перехвачено, вам, вероятно, лучше написать какой-нибудь общий обработчик исключений, заключив в него основной цикл программы - точную механику того, как это сделать, очевидно, зависит от того, на каком языке вы работаете в Там, журнал так подробно об исключении , как вы можете, сохранить состояние программы (где - то. другой , чем любые данные , хранить пользователь в настоящее время работает против - помните, что все это может быть поврежден в этой точке ), и так далее. Затем сбросьте исключение и позвольте ОС обработать его так, как он считает нужным. В этом универсальном обработчике исключений будьте готовы к катастрофическим сбоям, Затем, когда программа перезапускается, посмотрите, полезно ли это состояние, и восстановите то, что можно восстановить, если оно есть; и, возможно, предложить пользователю отправить вам сообщение об ошибке.


5
+1: Никогда не поймайте исключение, если вы не можете немедленно с ним справиться. (Увы, иногда вам нужно перехватить его, чтобы он снова мог свободно перемещаться, но помеченный как другой тип, как часть API-принуждения: я ненавижу это.)
Donal Fellows

6

В целом, использование try / catch настолько не рекомендуется, потому что catch-блок очень дорог с точки зрения ресурсов. Использование try / catch напоминает мне об управлении рисками . Управление рисками имеет два аспекта:

  1. Вероятность возникновения риска
  2. Ущерб, который он может иметь

Теперь, если вы выходите из дома, пианино, падающее на вашу голову где-то, вряд ли случится (возможно, 0,001%), но может вас убить.

Обработка исключений такая. Попробуйте блок не дорого. Но catch block действительно дорог, потому что для этого нужно создать таблицу трассировки стека и делать другие вещи. Поэтому, принимая решение о блоках try / catch, вы должны учитывать, сколько раз вы, вероятно, попадете в блок catch. Если среди 10000 использований вы нажмете только 1 раз, используйте его. Но если это форма, и пользователь, вероятно, не заполняет ее правильно 50% раз, тогда вам следует избегать применения блока try / catch.

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

try
{
    int result = a/b;
}
catch (DivisionByZeroException ex)
{
    // Showing a message here, and logging of course.
}

Вы должны написать:

if (b == 0)
{
    int result = a/b;
}
else
{
    // Showing a message to user to change the value of b, etc.
}

2
+1 за использование if / else для обработки «исключений», которые в основном являются просто логикой приложения.
Морган Херлокер

Если это связано с пользователем, помните, что компьютеры работают намного быстрее, чем люди. Исключение, выдаваемое в 50% отправленных форм, по-прежнему может произойти только несколько раз в секунду даже со многими пользователями.
Donal Fellows

1
Я не согласен с тобой во избежании блокировок try / catch. Постоянная попытка предвидеть исключения является склонной к ошибкам, дорогостоящей во время разработки и усложняющей чтение вашего кода. Цикл, который генерирует миллион исключений и перехватывает их, для запуска на моей машине занимает 500 мс (против 1 мс для пустого цикла), что не является реальной разницей в производительности в 99,99% случаев (и всего кода пользовательского интерфейса). Вы должны использовать исключения, за исключением случаев, когда вы знаете, что снижение производительности имеет значение, поскольку они делают ваш код более надежным и позволяют предположить, что предыдущий код был успешно выполнен.
Кайпро II

@ cosmic.osmo, ты получаешь трассировку стека или просто ловишь ее?

3

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


1
+1 для входа. Программы в дикой природе - это черные ящики. Когда они терпят неудачу, журнал с надписью «Вот что случилось» проходит очень долгий путь к решению проблемы. У меня были ошибки в моих программах, о которых не сообщалось, и они были обнаружены только после того, как я нашел их в журнале.
Эндрю Нили

2

Я лично терпеть не могу исключения, они очень, очень, очень трудно правильно обрабатывать. И попытка разорвать поврежденные данные ОЧЕНЬ, ОЧЕНЬ, ОЧЕНЬ сложно!

http://blogs.msdn.com/b/mgrier/archive/2004/02/18/75324.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

http://www.joelonsoftware.com/items/2003/10/13.html

Если вы не вызываете каждую функцию, как:

try
{
    TrivialFunction();
}
catch(TypeAException)
{
    //MaybeFix
}
catch(TypeBException)
{
    //MaybeFix
}
catch(TypeCException)
{
    //NO FIX - CORRUPT DATA
}
catch(TypeDException)
{
    //NO FIX - UNKNOWN STATE
}
catch(OutOfMemoryException)
{
    //Try to fix this one! Destructors might allocate on their own ;)
}
catch(Exception)
{
    //Nothing to see here, move on, everything is OK ;)
}

Вы не сможете правильно очистить каждую точку выхода. Исключения трудны!

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.