Исключение из модулей C # - PullRequest
       1

Исключение из модулей C #

2 голосов
/ 02 апреля 2012

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

Положение:

Модуль A ( с пользовательским интерфейсом ) получает событие "deleteitem". Аргументы события должны содержать имя элемента, который нужно удалить. Но в этом случае это ноль. Где-то кто-то что-то напутал.

Вопрос (ы):

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

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

Ответы [ 3 ]

5 голосов
/ 02 апреля 2012

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

3 голосов
/ 02 апреля 2012

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

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

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

То, что я здесь описал, лучше всего применимо к отдельным модулям, таким как службы WCF, например.Если это все в одном приложении (модули - это классы), вероятно, лучше всего было бы вернуть исключение, но убедитесь, что вызывающая сторона может его обработать.Поэтому разделение модулей здесь важно - чем больше разделение, тем выше устойчивость к ошибкам.Службы WCF или службы Windows не должны аварийно завершать работу.

1 голос
/ 02 апреля 2012

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

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

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

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

Дефекты продукта дешевле всего исправить, если они обнаружены относительно рано; но чрезмерное выбрасывание может вызвать распространение дефекта на несвязанные модули (которые получат некоторые, но не все связанные события) и, таким образом, задержит закрепление дефекта вниз.

...