2014-01-02 5 views
0

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

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

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

+1

Трудно охарактеризовать такую ​​неудачу как что-либо, кроме ошибки. Вы можете использовать класс 'Lazy <>', чтобы было легче получить право. –

ответ

0

Вы можете поймать все ваши необработанные исключения, используя Application.ThreadException event

+0

Хорошо, да, но что с ними делать? –

+0

Что бы вы ни хотели :) Я запишу их. Вы можете «отключить» их или что-то еще. –

+0

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

0

Это звучит немного неаккуратно. Вы можете уловить все исключения, добавив и обработчик событий в AppDomain.CurrentDomain.UnhandledException в свой файл program.cs. Это избавит вас от необходимости обернуть попытку обойти все. Однако это не настоящее решение. Вы должны обрабатывать исключения только в том случае, если вы можете сделать это успешно, и вы должны сделать это как локальное для проблемы, как вы можете получить.

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

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

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

1

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

Но прежде чем (сырая) обработка исключений попадает в фокус (например, nullArgumentException или InvalidIndexExcetion), лучше их предотвратить, проверив возможные проблемы внутри вашего кода или/и запишите модульные тесты, чтобы найти больше этих возможных проблем. При использовании объекта, состояние которого неизвестно, проверьте значение null. Если тип неизвестен, проверьте тип перед его использованием. Убедитесь, что индекс находится в границах, прежде чем использовать его ... Надеюсь, это поможет.

Смежные вопросы