Где лучше бросать исключения?

Question

[beduin01]

Никак не могу понять где лучше бросать исключения.
Прога при старте читает Config.ini Если он не найден, то нет смысла продолжать.

Я не могу понять как правильнее обработать этот сценарий. В классе ReadConfig если файл не найден мы бросаем исключение.
try
{
пробуем прочитать
если не получилось, то
бросаем исключение throw new Exception
}

catch()
{
при таком коде мы исключение поймаем в этом блоке
}

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

Или как правильнее сделать то?
}

Answer 1

[Daniil Danilov]

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

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

Comments

[beduin01]

Тоесть обернуть код создания экземпляра класса в try-catch?

[Daniil Danilov]

Обернуть код доступа к файлу Config.ini , если не найден, то формировать ошибку и возвращать её.

Answer 2

[Anatoliy Mikhailov]

Если это происходит внутри конструктора то ошибку нужно оформить только через throw.
А вот если твой класс ReadConfig читает конфиг с вызова его метода, то там можно вернуть null если что-то пошло не так. Такой вариант удобен чтобы не засорят код в местах вызова.

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

Comments

[beduin01]

"Если это происходит внутри конструктора то ошибку нужно оформить только через throw."
У меня именно такой сценарий. Получается, что мне тогда создание экемпляра класса в try-catch обернуть надо?

[Anatoliy Mikhailov]

beduin01: ну только так

[Daniil Danilov]

В конструкторе не вижу смысл акидать исключение, если доступ к файлу не получен, это не означает что "КонфигРидер" недееспособный объект и его не надо создавать, возможно юзер в дальнейшем сможет указать правильный файл, и загрузить его.

[Anatoliy Mikhailov]

Daniil Danilov: ну исходя из того что текущая логика свою работу делает в конструкторе - как удобным образом узнать что файла нет и нужно указать другой файл? А в случае если создавать исключение его просто будут ловить при вызове конструктора и там уже логировать и предлагать пользователю дальнейшее действие

[Daniil Danilov]

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

P.S. Что говарят евангелисты:

https://msdn.microsoft.com/en-us/library/ms229060(...

Answer 3

[MrDywar Pichugin]

Правила разработки исключений

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