Asp.net - лучшее место для отлова ошибок SQL Server SQL

Question

Для веб-приложений Asp.net лучше всего:

1. перехватывает ошибки в хранимых процедурах sql и проверяет возвращаемое значение в коде или
2. просто позвольте ошибке произойти в sql (не обрабатывайте ее) и полагайтесь на ado.net, вызывающей ошибки в коде.

Каковы лучшие практики здесь?

Answer 1

Общее правило, которое применяется здесь, заключается в том, чтобы перехватить ошибку как можно ближе к источнику. SQL Server теперь имеет синтаксис перехвата ошибок «try ... catch ...». Так что используйте это. Затраты на добавление небольшого количества дополнительного кода незначительны, и если в вашем SP есть несколько операторов, вы можете адаптировать строку в RAISERROR, чтобы помочь локализовать проблему.

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

Это одна из наиболее игнорируемых «лучших практик» в хранимых процедурах, и она даже важнее, чем в «обычном» коде, потому что сложнее использовать пошаговый отладчик.

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

Answer 2

В соответствии с этой статьей это тип исключения "с головой" - то есть, если в SP возникает ошибка, это означает, что с SP или самими данными что-то не так.

Я бы посоветовал перехватить ошибку в aps.net, так как там у вас гораздо больше возможностей зарегистрировать ошибку, а также все параметры, переданные SP для изучения проблемы.

Answer 3

Ответ в том, что вам нужно сделать оба. Некоторые ошибки на самом деле вызываются из ядра СУБД. Конечно, их источник зависит от способа подключения к базе данных (OLBC, OLEDB и т. Д.). Вы должны найти способ справиться с этим. Некоторые ошибки, такие как ошибки тупиковой ситуации, также должны обрабатываться на уровне приложений.

Помимо ошибок, рекомендуется получать и обрабатывать сообщения от компонента SQL Server Database Engine. Они очень похожи на ошибки и могут дать приложению много полезной диагностической информации. Если вы используете System.Data.SQLClient, вам необходимо создать делегат SqlInfoMessageEventHandler, идентифицирующий метод, который обрабатывает событие, для прослушивания события InfoMessage в классе SqlConnection. Вы обнаружите, что информация контекста сообщения, такая как серьезность и состояние, передается в качестве аргументов для обратного вызова, потому что с точки зрения системы эти сообщения похожи на ошибки. Надеюсь, это поможет!

Answer 4

Я бы сказал, что это зависит от того, что вы делаете в своем хранимом процессе и что вы хотите делать с определенными ошибками, которые происходят. Иногда я обращаюсь с этим в sp, но иногда я позволяю ему подняться до кода уровня данных.

Имейте в виду, иногда вы можете пропустить ошибки при использовании sql server 2005 try / catch, см. мой пост по этому вопросу. Принимая во внимание, что в коде (в моем случае C #) вы можете получить доступ ко всем ошибкам в объекте SqlErrorCollection.

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

Answer 5

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

Answer 6

Наиболее вероятным режимом сбоя на уровне данных является неверный ввод данных пользователем, например запрос несуществующей записи. Большинство других ошибок вызваны дефектным кодом и обычно сразу же обнаруживаются при тестировании. Мне нравится отлавливать ошибку БД и всегда выдавать пользовательскую ошибку с дополнительной информацией о данных и контексте запроса. Затем ошибка снова копирует стек вызовов, и если это была ошибка, исправляемая пользователем, я могу предупредить их об этом. В противном случае центральный обработчик страниц ошибок для приложения будет вызван, когда ошибка достигнет вершины стека. Худшее, что нужно сделать, это поймать ошибку и не дать ей всплыть. Коды возврата являются устаревшими конструкциями, если они не общаются с компонентами com или сторонними системами.

Answer 7

Я предпочитаю оба -

• хранимая процедура вызывает RAISEERROR, что проявляется как исключение в ADO.NET
• хранимая процедура возвращает код ошибки, если один sproc вызывает другой

В общем, я всегда делаю db-вызовы внутри try-catch

Answer 8

Я использую try / catch для всех потенциально генерирующих ошибку вызовов библиотек или других серверов, включая запросы к базе данных. Я в первую очередь разработчик, а не администратор баз данных, поэтому я обрабатываю ошибку на языке, которым я владею больше всего, C #, а не SQL. Я уверен, что это будет отличаться для каждого программиста. Не обрабатывать ошибки никогда не бывает хорошо в моей книге.