Рекомендуемый подход к обработке SqlExceptions в приложениях дб

Что ж, из базы данных вы будете получать только эти технические сообщения, например, «нарушение отношения внешнего ключа FK_something_to_another» или подобное.

Обычно в SqlException вы также получаете код ошибки SQL или что-то еще.

Лучшим подходом, вероятно, было бы иметь отдельную таблицу в вашей базе данных, которая в основном отображает те технические ошибки SQL, которые могут произойти с более значимыми, ориентированными на пользователя сообщениями. Например, если ваша ошибка SQL говорит что-то вроде «fk нарушение blablabaal», у вас может быть запись в вашей «UserErrorTable», которая сопоставляет это с сообщением пользователя, говорящим «не удалось удалить пользователя (this.and.that), скорее всего потому, что .. ... (он все еще член команды) "или что-то в этом роде.

Затем вы можете попытаться перехватить эти SqlExceptions на своем бизнес-уровне,

Обычно мы пишем какой-то переводчик в наших проектах. Мы сравниваем сообщение об исключении SQL с некоторыми предопределенными шаблонами и показываем эквивалентное сообщение пользователю

Для этого нужно написать хранимую процедуру и использовать TRY и CATCH . Используйте RAISERROR для создания собственных пользовательских сообщений и проверьте код ошибки в SqlException .

К сожалению, здесь нет простого ответа.

Объем работы будет зависеть от согласованности сообщений об ошибках, поступающих с бизнес-уровня. Вам потребуется выполнить некоторую форму перевода «технического» сообщения об ошибке в ваше ориентированное на пользователя сообщение.

Это должен быть вопрос выполнения некоторых форм поиска из ваших сообщений об ошибках в ключ ресурса, который может быть используется для вывода сообщения об ошибке для конкретного языка. Однако, если вам нужно проанализировать сообщения для получения дополнительной информации (например, имен таблиц и т. Д.), Тогда это станет немного сложнее. В этом случае вам, вероятно, понадобится что-то, что сопоставляет сообщение об ошибке с регулярным выражением / процессором некоторой формы, а также с новой строкой ресурса. Затем вы можете отформатировать пользователя '

Об общих технических> удобных для пользователя ошибках я могу подтвердить только те ответы, которые уже были даны.

Но в вашем конкретном примере с работодателем я должен призвать вас не полагаться только на SqlException. Прежде чем пытаться удалить сотрудника, вы должны проверить, является ли он / она частью какой-либо команды, менеджером и т. Д. Это значительно улучшит удобство использования вашего приложения.

Псевдо:

Employee e;
try {

   IEnumerable<Team> teams = Team.GetTeamsByEmployee(e);
   if (teams.Count() > 0) {
       throw new Exception("Employee is a part of team "+ String.Join(",", teams.Select(o => o.Name).ToArray());
   }

   IEnumerable<Employee> managingEmployees = Employee.GetEmployeesImManaging(e);
   if (managingEmployees.Count() > 0) {
       throw new Exception("Employee is manager for the following employees "+ String.Join(",", managingEmployees.Select(o => o.Name).ToArray());
   }

   Employee.Delete(e);
} catch (Exception e) {
   // write out e
}

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

Я склонен классифицировать ошибки как ожидаемые или непредвиденные. Если вы можете предвидеть ошибку и , вы хотите обработать ее с помощью четкого консисного сообщения, например, с вашей ситуацией «удалить сотрудника», вам придется соответствующим образом спланировать и закодировать. По их определению, вы не можете сделать это для непредвиденных ошибок - обычно здесь на помощь приходит TRY / CATCH.

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

Альтернатива, основанная на TRY ... CATCH ... быть, чтобы проверить номер ошибки в блоке catch. Если это «невозможно удалить из-за внешнего ключа», вы можете запросить дочерние таблицы и сгенерировать сообщение, а если это какая-то другая непредвиденная ошибка, вам придется вернуться к общему сообщению.

(Предупреждение: иногда, когда возникает ошибка, SQL выдаст два сообщения об ошибках подряд [одно из них - нарушение ограничения FK?], И в этих ситуациях различные функции ERROR () будут возвращать данные только для второго и неизменно менее полезного сообщения. Это очень неприятно, но с этим ничего не поделаешь.)

Короткий ответ - «не надо». Позвольте ошибкам всплыть в глобальную обработку ошибок / регистрацию. Правила проверки и бизнес-правила должны, как правило, исключать исключения из базы данных, так что лучше отказываться от ошибок и не отправлять грязные данные. Транзакции тоже помогают.