Перехват исключений в качестве ожидаемого управления потоком выполнения программы?

Я всегда чувствовал, что ожидать исключения на регулярной основе и использовать их в качестве логики потока было плохой вещью. Исключения чувствуют, что они должны быть, ну, "исключение», Если ты'Вы ожидаете и планируете исключение, которое, по-видимому, указывает на то, что ваш код должен быть реорганизован, по крайней мере, в .NET ...

Тем не мение. Недавний сценарий заставил меня задуматься. Я опубликовал это на MSDN некоторое время назад, но яЯ хотел бы больше поговорить об этом, и это идеальное место!



Так скажиу нас есть таблица базы данных, у которой есть внешний ключ для нескольких других таблиц (в случае, когда изначально возникла дискуссия, на нее указывали 4 внешних ключа). Вы хотите разрешить пользователю удалять, но только если нет ссылок на внешние ключи; ты неТ хочу каскадно удалить.

Обычно я просто проверяю, есть ли ссылки, и, если они есть, я информирую пользователя, а не делаю удаление. Это'Очень легко и просто написать, что в LINQ связанные таблицы являются членами объекта, поэтому в Section.Projects и Section.Categories и т. д. удобно набирать с помощью intellisense и всего ...

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



Руководитель этого проекта попросил меня изменить его, чтобы он просто перехватывал SqlException с кодом 547 (ограничение внешнего ключа) и обрабатывал его таким образом.



Я был...

упорная.



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

Кроме того, база данных действительно должна отвечать за обработку ссылочной целостности, которая 'это его работа, и она делает это хорошо ...

Таким образом, они выиграли, и я изменил это.



На каком-то уровне это все еще чувствуетнеправильно для меня все же.



Что вы, ребята, думаете об ожидающих и намеренно обработанных исключениях? Это нормально, когда это выглядит такбудет эффективнее, чем проверять заранее? Это больше сбивает с толку следующего разработчика, смотрящего на ваш код, или меньше сбивает с толку? Насколько это безопаснее, поскольку база данных может знать о новых ограничениях внешнего ключа, о которых разработчик может и не подумать, чтобы добавить проверку? Или это вопрос перспективы того, что именно вы считаете лучшей практикой?

Ответы на вопрос(8)

Ваш ответ на вопрос