Для веб-приложений Asp.net лучше всего:
Каковы лучшие практики здесь?
Общее правило, которое применяется здесь, состоит в том, чтобы поймать ошибку как можно ближе к источнику. SQL Server теперь имеет синтаксис перехвата ошибок "try... catch...". Так что используйте его. Накладные расходы на небольшой дополнительный код незначительны, и если у вас есть несколько операторов в SP, вы можете адаптировать строку в RAISERROR, чтобы помочь локализовать проблему.
В интерфейсе не должно быть сложно перехватить событие ошибки SP и обработать его так же, как вы обрабатываете другие перехваты ошибок в своем процедурном коде.
Это один из самых игнорируемых «лучших методов» в хранимых процедурах, и он даже важнее, чем в «обычном» коде, потому что использовать пошаговый отладчик сложнее.
Одним из полезных шаблонов является обработка этого в вашем SP так же, как вы ожидаете, что это будет обрабатываться в любой другой непрозрачной библиотеке SDK.
Согласно этой статье, это тип "тупоголового" исключения - т.е. если в SP возникает ошибка, это означает, что что-то не так с SP или самими данными.
Я бы посоветовал ловить ошибку в aps.net, так как там у вас гораздо больше возможностей для регистрации ошибки, а также всех параметров, переданных в SP для исследования проблемы.
Я использую try/catch для всех потенциально ошибочных вызовов библиотек или других серверов, включая запросы к базе данных. Я в первую очередь разработчик, а не администратор базы данных, поэтому я обрабатываю ошибки на языке, в котором я лучше всего разбираюсь, C #, а не в SQL. Я уверен, что это будет варьироваться для каждого программиста. Не обрабатывать ошибку никогда не бывает хорошо в моей книге.
Я предпочитаю оба -
в общем, я всегда делаю вызовы db внутри try-catch
Наиболее вероятным режимом сбоя на уровне данных являются неправильные входные данные пользователя, например запрос несуществующей записи. Большинство других ошибок вызваны дефектным кодом и обычно выявляются сразу при тестировании. Мне нравится ловить ошибку базы данных и всегда выдавать пользовательскую ошибку с дополнительной информацией о данных и контексте запроса. Затем ошибка всплывает в стеке вызовов, и если это ошибка, которую может исправить пользователь, я могу предупредить их об этом факте. В противном случае центральный обработчик страницы ошибок для приложения будет вызываться, когда ошибка достигает вершины стека. Худшее, что можно сделать, это поймать ошибку и не дать ей снова всплыть. Коды возврата являются устаревшими конструкциями, если только они не обращаются к ком-компонентам или сторонним системам.
В идеале ваше веб-приложение не знает о серверной части или доступе к данным. Таким образом, он не должен обрабатывать ошибки, связанные с sql, - их должен обрабатывать уровень доступа к данным. Но веб-приложение должно корректно реагировать на сбои, предоставляя конечному пользователю дружественное сообщение.
Я бы сказал, что это зависит от того, что вы делаете в своей хранимой процедуре, и что вы хотите делать с некоторыми возникающими ошибками. Иногда я обрабатываю это в sp, но иногда я позволяю ему подняться до кода уровня данных.
Имейте в виду, что иногда вы можете пропустить ошибки при использовании sql server 2005 try/catch, см. message">мой пост об этом. Принимая во внимание, что в коде (в моем случае C#) вы можете получить доступ ко всем ошибкам в объекте SqlErrorCollection.
Просто будьте абсолютно уверены, что ваша обработка ошибок в хранимой процедуре хорошо продумана, и любые неопределенности оставлены для передачи в код уровня данных, где вы должны все регистрировать.
Ответ заключается в том, что вам нужно сделать и то, и другое. Некоторые ошибки на самом деле вызываются нижестоящим механизмом базы данных. Их источник, конечно, различается в зависимости от фактического способа подключения к базе данных (OLBC, OLEDB и т. д.). Вы должны найти способ справиться с этим. Некоторые ошибки, такие как ошибки взаимоблокировки, также должны обрабатываться на уровне приложения.
Помимо ошибок, рекомендуется получать и обрабатывать сообщения от ядра СУБД SQL Server. Они очень похожи на ошибки и могут дать приложению много полезной диагностической информации. Если вы используете System.Data.SQLClient, вам потребуется создать делегат SqlInfoMessageEventHandler, определяющий метод, обрабатывающий событие, для прослушивания события InfoMessage в классе SqlConnection. Вы обнаружите, что информация о контексте сообщения, такая как серьезность и состояние, передается в качестве аргументов функции обратного вызова, потому что с точки зрения системы эти сообщения подобны ошибкам. Надеюсь, это поможет!
