Если вы перехватываете SettingsFileNotFoundException
на другом уровне (в другом вызывающем методе), тогда может иметь смысл создать пользовательское исключение, поскольку вам может потребоваться определить, в чем именно заключалась ошибка.Ниже приведен упрощенный пример:
void startingMethod()
{
try
{
secondMethod();
thirdMethod();
}
catch (SettingsFileNotFoundException sfnfe)
{
// Handle all SettingsFileNotFoundException issues here.
}
catch (Exception ex)
{
// Handle all other exceptions here.
}
}
void secondMethod()
{
// TODO: secondMethod actions.
var fileName = SomeLogicSpecificToSecondMethodHere();
if (!File.Exists(fileName))
{
throw new SettingsFileNotFoundException("...");
}
}
void thirdMethod()
{
// TODO: thirdMethod actions.
var fileName = SomeOtherLogicSpecificToThirdMethodHere();
if (!File.Exists(fileName))
{
throw new SettingsFileNotFoundException("...");
}
}
В приведенном выше примере программа ищет несколько файлов настроек и, таким образом, имеет несколько операторов throw ()
, которые используют исключение.И перехват вложенных исключений позволяет обрабатывать все эти исключения одним и тем же способом, не помещая один и тот же код в ваши два вторичных метода.В данном случае наличие пользовательского исключения в качестве другого типа позволяет обрабатывать это конкретное исключение не так, как остальная часть вашей обработки ошибок.
Но, если предположить, что вы не занимаетесь этой фантазией по обработке ошибок, первоеописанный вами подход лучше, потому что он обобщен.Зачем создавать исключение, которое может быть выдано только один раз?Я предполагаю, что вы кешируете свои настройки в переменных, поэтому вам не нужно читать файл каждые пять секунд, что ограничивает возможность использования нового исключения во время инициализации приложения.
в вашем случае, если вы, скорее всего, не будете расширять свой код для использования более сложной обработки ошибок в будущем, вам, вероятно, следует просто использовать очень конкретное сообщение для исключения FileNotFoundException.