В своем предыдущем посте я начал рассказывать о своем путешествии во время моего трудового опыта работы с кодовыми базами PL / SQL, проблемах, с которыми я столкнулся, и потенциальных решениях для них, чтобы создать приятную среду. Я говорил о последствиях наличия первичных ключей со слишком большим количеством полей, и в этом случае мы рассмотрим ошибки управления ошибками и то, как лучше подойти к этому.
Когда я работал инженером службы поддержки, мне приходилось каждую неделю отвечать на сообщения разгневанных пользователей об ошибках. Они присылали мне скриншоты пути и сообщений об ошибках, затем я просматривал изображения, обнаруживал модуль с ошибкой, находил контроллер Java, сканировал файл, чтобы увидеть, какие модули PL/SQL они вызывали, а затем пытался отлаживать модуль. unit, если проблема заключалась в нем (поскольку файлы журналов Java были слишком большими и болезненными для игры).
Это было много ненужной работы, чтобы просто обнаружить источник ошибки. Однажды днем, читая Программирование Oracle PL/SQL по дороге в колледж, я наткнулся на раздел управления ошибками, и это было похоже на зов с небес. Все языки программирования и фреймворки имеют механизмы управления ошибками, и этот не исключение.
Избавьтесь от ошибок кода возврата!
Я очень часто вижу кодовые базы с таким «стилем» управления ошибками, когда они передают параметры IN/OUT программам с кодами ошибок и сообщениями для проверки после каждого вызова, например:
Вызывающая программа должна будет реализовать некоторые проверки, подобные этой:
Это слишком много хлопот, с этим подходом есть несколько проблем:
- Повторение кода, мы должны писать одни и те же ошибки кода и сообщения, переменные, параметры и проверки в КАЖДОЙ программе.
- Перепутав коды ошибок, мы почти на 100% уверены, что будут ошибки с тем же кодом, но с разными сообщениями.
- Склонен к ошибкам, все эти ручные проверки легко испортить, и мы можем случайно обнаружить некоторые ошибки.
- Нет дополнительной информации о среде, вызвавшей ошибку, что затрудняет ее воспроизведение.
- Нет регистрации ошибок, что еще больше усложняет отладку.
Предварительное решение:
Чтобы решить эти проблемы, мы хотели бы сначала создать таблицу для кодов ошибок и сообщений.
Нам нужно создать пакет, определяющий константы кодов ошибок и функции, возвращающие эти константы, чтобы мы могли вызывать их из операторов SQL. Мы определяем код ошибки (c_invalid_error_id), чтобы вызвать исключение, чтобы убедиться, что мы используем только допустимые коды ошибок для создания бизнес-исключений.
Вставим код ошибки и сообщение в таблицу с помощью нашей функции.
Нам также понадобится пакет для легкого выявления бизнес-ошибок.
Давайте посмотрим, как мы используем новые инструменты, чтобы переделать нашу первоначальную процедуру:
И новый абонент:
Намного чище, не так ли? Теперь у нас меньше кода, нет повторений кода, простой механизм и контроль над нашими кодами ошибок и сообщениями!
Хотя чего-то не хватает..
Регистрируйте свои ошибки!
Регистрация наших программ облегчит их отслеживание и значительно упростит отладку. В Oracle Open Source есть фреймворк ведения журналов, который я использую и рекомендую, и вы можете найти его здесь. Его очень просто установить, и вам не нужно изобретать или обслуживать колесо.
Давайте посмотрим на финальный вид наших процедур с логгером:
В разделе объявления мы определили область действия (которая является процедурой) и контейнер параметров (tab_param). В исполняемой секции мы добавляем параметры к контейнеру. А в блоке исключений логируем ошибку с областью видимости и затем таблицей параметров.
Наша вызывающая процедура будет выглядеть так:
Logger будет хранить всю ту информацию, которая нам нужна, чтобы сделать наш процесс отладки более приятным, мы будем знать, в каком блоке, в какое время, какая ошибка и какие параметры были переданы!
Удачного кодирования!
