Должен ли весь linq, который получает объект базы данных, быть окружен попыткой?

Question

Должны ли все запросы linq, которые возвращают сущность, быть окружены попыткой catch?

Например:

phase.Container = containers.Where(cont => cont.ContainerId == phase.ContainerId).SingleOrDefault();

Это не вызовет сбой приложения, но вызовет исключениеесли объект Контейнер отсутствует.

РЕДАКТИРОВАТЬ

Даже при этом все равно будет отображаться исключение:

bool schedValid = false;
foreach (var s in schedules)
{
 if (s.ScheduleId == phase.ScheduleId) schedValid = true;
}
if (schedValid)
{
 phase.Schedule = schedules.SingleOrDefault(sc => sc.ScheduleId == phase.ScheduleId);
}
else
{
 phase.Schedule = null;
}

Редактировать 2

Причина всех этих усилий заключается в том, что если родительский объект удален, то дочерние объекты, содержащие данные, все равно должны быть разрешены для просмотра, даже если их родительский объект пропал.Можно привести аргумент, что родительский объект не должен быть удален.Справедливо, но нет смысла держать это в руках, когда дети стали более значимыми, чем родитель, и по какой-либо причине родитель больше не должен быть сохранен.Позднее дочерние объекты могут быть переназначены другому родительскому объекту.

Answer 1

Это ответ на вопрос в заголовке, а не конкретный пример, приведенный в тексте вопроса.

"Это зависит"

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

См. Этот великолепный пост от Эрика Липперта для более подробной информации об обработке исключений.
http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx

Answer 2

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

Вы можете обрабатывать распространенные исключения, которые могут быть сгенерированы LINQ с сообщением по умолчанию / широким, и обрабатывать более точные ошибки вокруг вашего LINQ.

Вот список известных исключений, которые могут быть сгенерированы изэтот вопрос :

• SqlException
• ChangeConflictException
• DuplicateKeyException
• ForeignKeyReferenceAlreadyHasValueException
• исключение, когда исключениеправильно утилизируя DataContext)

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

Если вы знаете, что точное выражение LINQЕсли у вас возникли проблемы, то вы можете за один раз обернуть его с помощью Try / Catch aи управлять им соответственно.

Answer 3

Единственное исключение, которое я видел, когда ваш фрагмент кода выбрасывает (при условии, что он компилируется), это NRE.Если phase или containers равны нулю, или если containers содержит null значения, вы получите исключение NullReferenceException.

Я бы ожидал их в коде, хотя, чтобы избежать использования try / catch путем явной проверки их значений перед использованием:

if (phase != null && containers != null)
    phase.Container = containers
                        .Where(cont => cont != null)
                        .SingleOrDefault(cont => cont.ContainerId == phase.ContainerId);

Исключения обходятся дорого ... делайте все возможное, чтобы их избежать.

---

ОБНОВЛЕНИЕ

Учитывая тот факт, что вы в настоящее время намеренно осуждаете записи и не можете доверять своей базе данных, я бы рекомендовал использовать блоки try / catch для всего вашего кода ...

Плохой дизайн базы данных / приложения требует не менее плохого кода.

Правильный ответ здесь - исправить ваш дизайн.