Где поставить try catch

Ответ 1

Следуем

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

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

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

Ответ 2

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

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

Ответ 3

Манда по обработке исключений: "Бросьте рано, поймай поздно". Вы хотите поймать исключения в последний возможный момент, но вы хотите немедленно их бросить (не выполняйте больше обработки после определения того, что что-то не так, а затем генерирует исключение). Если вы не можете "обработать" исключение, то не поймайте его.

В большинстве случаев Try... Наконец, блоки должны быть гораздо более распространены в вашем коде, чем Try... Catch.

Ответ 4

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

try
{
    //do something 
}
catch(Exception ex)
{
    LogFile.WriteLine(ex.ToString());
    throw;
}  

Примечание: не пишите:

throw ex;

так как это очистит всю полезную информацию стека от исключения.

Ответ 5

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

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

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

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

Конечно, это просто совет. YMMV.:)

Ответ 6

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

Я рассматриваю, что делать с ошибками в бизнес-правиле. Он должен быть отделен от слоя данных или слоя ui.

Ответ 7

Общий ответ: поймать в любое время, когда вы сможете справиться с тем, что бросается. То есть решение довольно просто. Например, перехватывайте исключения, возникающие при создании требуемого объекта.

Ответ 8

Всегда пытайтесь/улавливать уровень верхнего уровня или contoller.

Ответ 9

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

Ответ 10

Когда у меня есть многослойная архитектура, подобная этой (это очень много), я часто получаю try/catch на более чем одном уровне. Например, попытка/улов на уровне персистентности, которая улавливает SQLException, выполняет то, что должен выполнить уровень персистентности (например, уведомлять администратора), а затем генерирует новое исключение, которое будет иметь смысл для некоторого кода, который вызывает уровень сохранения, Примером может быть PersistenceException. Следующий слой вверх не заботится о том, кто должен быть уведомлен о перезапуске базы данных, но он заботится о том, чтобы он не мог сохранить пользовательское состояние, поэтому он мог бы поймать PersistenceException и сказать пользователю, что его новый номер телефона не был " t хранится в базе данных.

Ответ 11

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

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

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