Лучшие практики для определения Ваших собственных классов исключений?
Удалось найти решение. Я установил это в событии Global.asax Application_Start (), чтобы перезаписать настройки в файлах конфигурации.
var appSettings = ConfigurationManager.AppSettings;
var config = ImageProcessorConfiguration.Instance;
var cachedStorageAccount = appSettings["CachedStorageAccount"];
if (!string.IsNullOrEmpty(cachedStorageAccount))
{
config.ImageCacheSettings["CachedStorageAccount"] = cachedStorageAccount;
}
5 ответов
Да, это - хорошая практика для наследования std::runtime_error или другие стандартные классы исключений как std::logic_error, std::invalid_argument и так далее, в зависимости от которого вида исключения это.
Если все исключения наследовали некоторый путь от std::exception легко зафиксировать все распространенные ошибки a catch(const std::exception &e) {...}. Если у Вас есть несколько независимых иерархий, это становится более сложным. Получение из специализированных классов исключений заставляет эти исключения содержать больше информации, но насколько полезный это действительно, зависит от того, как Вы делаете свою обработку исключений.
Я не разработчик C++, но одна вещь, которую мы сделали в нашем коде C#, была, создают исключение базового класса для нашей платформы и затем регистрируют исключение, добавленное конструктор:
public FrameworkException(string message, Exception innerException)
: base(message, innerException)
{
log.Error(message, innerException);
}
...
Любое полученное исключение просто должно вызвать, это - основной конструктор, и мы получаем последовательное исключение, регистрирующееся повсюду. Не грандиозное предприятие, но полезный.
Это - польза, когда исключение помещается в некоторый объем. Например, класс Управление может объявить внутреннюю Ошибку классов исключений.
и поймайте их как
catch ( const Manipulation::InputError& error )
catch ( const Manipulation::CalculationError& error )
В таких случаях они могут быть просто пустыми классами без любой дополнительной информации об ошибке, если Вы не разрабатываете, разрешает ту муху исключений, очень верхнюю, где Вы ловите все стандартные исключения.
По-моему, не имеет значения, если Вы наследовались станд.:: исключение или нет. Для меня самая важная вещь об определении исключений:
- Наличие класса исключений называет быть полезным и ясным.
- Очевидно документирование (пишущий комментарии), когда исключение будет выдано функциональным или методом класса. Это - единственное самое большое место ошибки в обработке исключений, по-моему.
Это не имеет большое значение с тех пор std::runtime_error также наследовался std::exception. Вы могли утверждать, что ошибка периода выполнения передает больше информации об исключении, но на практике, люди часто просто происходят из основного класса исключений.