Обработка исключений

голоса
2

Структурирована обработка исключений плохо? Что такое правильный способ обработки исключений?

EDIT: Обработка исключений в .NET с использованием C #.

У меня обычно есть набор конкретных классов исключений (DivideByZeroException, ArrayTypeMismatchException) и не имеют общий «поймать (Exception ех)».

Доводы в том, что я ожидаю определенные типы исключений встречаются и имеют конкретные действия, определенные при их возникновении и неожиданные исключения будут расти вверх интерфейс (либо окна или веб-сайтов). Это хорошая практика?

Задан 09/12/2008 в 15:31
источник пользователем
На других языках...                            


5 ответов

голоса
6

Я не уверен, что вы имеете в виду под «структурированной обработки исключений».

Самое худшее, что может быть сделано в обработке исключений является «ласточка» исключение или обрабатывать его молча.

Не делай это:

try {
   ...
}
catch (Exception e) {
   //TODO: handle this later
}

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

Ответил 09/12/2008 в 15:39
источник пользователем

голоса
3

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

Ответил 09/12/2008 в 15:33
источник пользователем

голоса
1

Это сложная тема ... есть книги на этом ... но ... Есть два основных типа обработки исключений ... рядный, где код для рассмотрения возможных ошибок рядного с кодом, что методом или процедурой будет «нормально» выполнить, и структурированную обработку исключений, где код находится в другом месте, и Дэ инфраструктура предназначена для автоматического switych к этому коду обработки исключений, когда происходит неожиданное событие (ошибка) ... Оба имеют advantedges и disadvanteges. «Инлайн» подход имеет тенденцию производить код, который является гораздо более суматохой (с кодом ошибки) и труднее читать и поддерживать. Но это легче производить авансом, поскольку он не требует какого-либо авансового анализа При использовании встроенной обработки ошибок, вы часто видите методы, возвращающие логическую или числовую «ошибка» коду, indiocating к абоненту, был ли metjhod или рутина успешным. Это устраняет «функциональный» синтаксис, имеющие обычное «возвращение» содержательные стоимости бизнеса или объект (так как любую функция по соглашению должны возвращать код ошибки) При использовании структурированной обработки исключений, этот вопрос является спорным.

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

Одна вещь, конечно, не смешивать эти два подхода в одном компоненте ...

Ответил 09/12/2008 в 15:59
источник пользователем

голоса
1

Моя рекомендация:

Не поймать исключение, если:

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

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

Ответил 09/12/2008 в 15:45
источник пользователем

голоса
0

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

  • Ваш код делает то, что в C ++ стандарт производит неопределенный или определенное реализацией поведение (например, деление на ноль).
  • Windows, определяет, что с поддержкой SEH он бросает исключение в этом случае.
  • Вы используете этот факт, чтобы поймать исключение и / или выполнить обработчик завершения.

Таким образом, вопросы, чтобы спросить, ИМО, являются:

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

Если ответы «да», «да», «нет», то структурированная обработка исключений требуется. В противном случае вы можете быть в состоянии избежать этого, в этом случае вы, вероятно, хотите. Написание исключения безопасного кода сложно, поэтому сильнее исключение гарантирует, что Вы можете предложить лучше. Код, который может быть делит на ноль с SEH не предлагает гарантию nothrow, когда, возможно, с небольшим количеством редизайна, так что абоненты не дают ему данные Дафф, он может сделать это. Но если функция уже есть бросать исключения по другим причинам, то и, возможно, бросая их на аппаратные ловушки не может сделать вещи не хуже.

Заметный Особый случай является распределением памяти. Не уверен , что если .NET делает это, но на распределении Linux только терпит неудачу , если есть недостаточное виртуальное адресное пространство для размещения. Физическая память совершается при первом использовании, и вызывает аппаратное исключение , если не хватает. Поскольку распределение памяти должен бросить зЬй :: bad_alloc на провал, а реализация не выполняет это требование стандарта, можетв том, что в некоторых случаях, преобразующих аппаратное исключение программного обеспечения является то, что нужно делать. Тем не менее, что аппаратное исключение может произойти в неожиданных местах (в том числе и в подпрограммах вы считали nothrow), так что может быть невозможным, чтобы справиться с грациозно, поэтому ядро ​​Linux свалки, а не бросать. На практике, все, что получает полностью инициированное разобьет его конструктор, который часто достаточно близко к распределению, что исключение программного обеспечения, а не было бы полезно.

Ответил 09/12/2008 в 16:06
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more