Все об исключениях: что делать и куда заходить? - PullRequest
3 голосов
/ 02 июня 2009

Мой вопрос состоит из двух частей, отсюда и неоднозначное название.

Часть первая

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

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

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

Часть вторая

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

Глупые вопросы требуют глупых ответов.

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

Ответы [ 5 ]

5 голосов
/ 02 июня 2009

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

Вот Microsoft Руководство по передовым методам обработки исключений

И будет много других ...

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

Вопрос 1: Хотите ли вы, чтобы приложение могло продолжать работу, если было выдано исключение? Тогда я бы «проглотил» исключение.

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

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

2 голосов
/ 02 июня 2009

Блог группы анализа кода - отличное место для начала изучения этой темы. Также посмотрите на

Мартин Фаулер - Fail Fast

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

Проверено против непроверенных исключений

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

1 голос
/ 02 июня 2009

Часть первая

Как правило, вы не хотите, чтобы в блоке перехвата возникало поведение, генерирующее исключения.

try
{
   ExceptionThrowingMethod();
}
Catch(Exception ex)
{
   //Log It
   //Try Again
   ExceptionThrowingMethod();
}

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

  1. Записать ошибку. Всегда. Даже если вы установили его на самый низкий уровень ведения журнала и никогда не читаете эти журналы.
  2. Определите, можно ли восстановить ваше текущее состояние. (Правильные переменные установлены или равны нулю? Они ломались во время критической функции или между ними?)
  3. Если вы можете восстановить, установите некоторые переменные, которые обозначают «повторную попытку», и разрешите выполнению выполнять OUT из блока catch. Если вы не можете восстановить, попробуйте добавить контекст, а затем повторно выдать ошибку.

Блоки Catch предназначены для восстановления после ошибок, а не для обычного выполнения. Таким образом, даже с помощью FileNotFound это исключительное явление, когда пользователю предлагается попытаться найти свой файл , а не , и поэтому это должно произойти в его собственном try-catch (или в обратном цикле к исходному).

Часть вторая

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

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

0 голосов
/ 03 июня 2009

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

0 голосов
/ 02 июня 2009

Вот несколько рекомендаций по обработке исключений.

Лучшие практики для управления исключениями в Java или C #

...