Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
21.12.2018, 08:28
|
|||
|---|---|---|---|
|
|||
Какая существует практика правильности обработки ошибок |
|||
|
#18+
Добрый день. Если учитывать тот факт, что вся бизнес логика находится на стороне БД, то "верхнее ПО" как то нужно информировать, что "что-то" пошло не так. Хранимые процедуры имеют результирующий код: Код: sql 1. 2. 3. 4. 5. 6. 7. Если подумать, то в самом простом применении данный код можно использовать как "0" - ошибок нет, "не 0" - некая ошибка. Если бизнес логика БД проверяет правильность входящих данных, то должно быть ещё и описание ошибки в том случае, если данные не прошли проверку. Для возвращение описания ошибки "верхнему ПО" в голову приходит "Print @описание_ошибки". Могут быть ошибки при непосредственной модификации данных (insert/update/delete) связанные например с установленными ограничениями при создании таблиц. Такие ошибки можно отлавливать через: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Как по Вашему мнению, такой подходи отлова ошибок/предупреждений является правильным подходом? есть что-то, что в данном подходе можно улучшить? Возможно есть и другие способы, как можно уведомить "верхнее ПО" о наличии ошибок и предупреждений, очень буду признателен за советы, как это можно делать по другому и более правильней... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.12.2018, 14:03
|
|||
|---|---|---|---|
Какая существует практика правильности обработки ошибок |
|||
|
#18+
Код: sql 1. 2. наше фсе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.12.2018, 14:03
|
|||
|---|---|---|---|
|
|||
Какая существует практика правильности обработки ошибок |
|||
|
#18+
Игорь_UUS, а что с транзакциями делать? Вы пишете устаревший RAISERROR(). Существует механизм исключений в современных средствах разработки, его и надо использовать. Если исключения приложением не могут быть обработаны в силу реализации средства разработки, то придется использовать код завершения. В некоторых случаях приложения должно "мягко" реагировать, тогда можно использовать код завершения. Смотреть по требованиям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.12.2018, 14:06
|
|||
|---|---|---|---|
|
|||
Какая существует практика правильности обработки ошибок |
|||
|
#18+
Игорь_UUS, подумайте, например, как можно предоставить пользователю в понятной форме сообщения проверочных ограничений, нарушения ограничений уникальности и проверки внешнего ключа, если это требуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=46&mobile=1&tid=1688554]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
40ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
36ms |
get tp. blocked users: |
2ms |
| others: | 257ms |
| total: | 386ms |

| 0 / 0 |
