Когда использовать блоки попытки/выгоды?
Это - то, как я делаю свои процедуры хранилища MSSQL с автоматически сгенерированным идентификатором.
CREATE PROCEDURE [dbo].[InsertProducts]
@id INT = NULL OUT,
@name VARCHAR(150) = NULL,
@desc VARCHAR(250) = NULL
AS
INSERT INTO dbo.Products
(Name,
Description)
VALUES
(@name,
@desc)
SET @id = SCOPE_IDENTITY();
5 ответов
Основное практическое правило для перехвата исключений - перехватить исключения тогда и только тогда, когда у вас есть значимый способ обработка их .
Не перехватывайте исключение, если вы собираетесь только зарегистрировать исключение и выбросить его в стек. Это не имеет смысла и загромождает код.
Нужно ли поймать исключение, когда вы ожидаете сбоя в определенной части вашего кода, и если у вас есть запасной вариант для этого.
Конечно, у вас всегда есть случай проверенных исключений, требующих использования блоков try / catch, в этом случае у вас нет другого выбора. Даже с отмеченным исключением убедитесь, что вы ведете журнал правильно и обрабатываете как можно более чисто.
Исключения и обработка исключений (Руководство по программированию на C #)
Исключения и обработка исключений (Руководство по программированию C #) Обновленная ссылка (от MS), хотя другая ссылка все еще актуальна.
Исключение Обработка (Руководство по программированию на C #)
Как говорили некоторые другие, вы хотите использовать блок try catch вокруг кода, который может генерировать исключение, И с которым вы готовы иметь дело.
В конкретных примерах File.Delete может генерировать ряд исключений, включая IOException, UnauthorizedAccessException, а также другие. Что бы вы хотели, чтобы ваше приложение делало в таких ситуациях? Если вы попытаетесь удалить файл, но его использует кто-то еще, вы получите исключение IOException.
try
{
File.Delete(pgpdFilename + "_archive")
}
catch(IOException)
{
UtilityLogger.LogToFile("File is in use, could not overwrite.");
//do something else meaningful to your application
//perhaps save it under a different name or something
}
Также имейте в виду, что если это не удастся, то File.Move, который вы выполняете за пределами вашего блока if next, также потерпит неудачу (снова в IOException - поскольку файл не был удален, он все еще там, что приведет к перемещению потерпеть неудачу).
Меня учили использовать try / catch / finally для любых методов / классов, в которых могут возникнуть множественные ошибки, и , с которыми вы действительно можете справиться . Транзакции базы данных, ввод-вывод файловой системы, потоковая передача и т. Д. Основная логика обычно не требует try / catch / finally.
Самое замечательное в try / catch / finally состоит в том, что у вас может быть несколько захватов, так что вы можете создать серия обработчиков исключений для обработки очень конкретной ошибки или использования общего исключения для обнаружения любых ошибок, которые вы не видите.
В вашем случае вы используете File.Exists, что хорошо, но у них может быть другая проблема с диском, которая может вызвать другую ошибку, которую File.Exists не может обработать. Да, это логический метод, но предположим, что файл заблокирован, и что произойдет, если вы попытаетесь записать в него? С уловкой вы можете спланировать редкий сценарий, но без try / catch / finally вы можете подвергнуть код совершенно непредвиденным условиям.
The other guys have given quite a number of good pointers and references.
My input is a short one:
When to use it is one thing, equally or more importanly is how to use it properly.
PS: "it" is refeings to "trying-catching exceptions".