Исключения в PostgreSQL — не всё то золото, что блестит Когда я только погружался в кодовую базу PostgreSQL и Pangolin, меня по-настоящему порадовали две вещи. Во-первых, автоматическое управление памятью через memory contexts — мощный и при этом довольно изящный механизм. Во-вторых, наличие исключений. В тот момент это выглядело почти как подарок: С-код, но с привычными абстракциями, которые обычно ассоциируются с более высокоуровневыми языками. При этом в сами исключения я долго не лез. Они просто существовали где-то рядом: встречались в коде, выглядели знакомо, и этого было достаточно. В PostgreSQL есть PG_TRY, PG_CATCH и PG_FINALLY, и на уровне синтаксиса всё это выглядит настолько похоже на исключения из Java или Python, что очень сложно не провести прямую аналогию. Я, по крайней мере, её провёл — и довольно надолго. В голове сложилась простая и, как потом выяснилось, ложная модель. Если внутри PG_TRY происходит что-то плохое, управление передаётся в PG_CATCH, там мы это обрабатываем и дальше спокойно продолжаем работу. Ровно так, как это работает в большинстве языков программирования. Ничего экзотического, всё привычно. С этой моделью я и подошёл к одной из рабочих задач. Мне нужно было делать бинарную десериализацию из области памяти, и в этом месте некорректные данные — не что-то из ряда вон выходящее, а вполне ожидаемый сценарий. Данные могут быть повреждены, устаревшими или просто не соответствовать формату, и код должен уметь это переживать. Для этого я написал небольшой фреймворк для бинарной (де)сериализации, опираясь именно на исключения: если данные некорректны — «бросаем исключение», клиентский код его ловит и идёт по альтернативной ветке, считая, что десериализация не удалась. На первый взгляд всё работало идеально. Код был аккуратный, тесты проходили, никаких проблем не возникало. И довольно долго ничего не намекало на то, что под этой конструкцией есть какая-то фундаментальная ошибка. Проблемы начались ровно в тот момент, когда мы стали осознанно тестировать сценарии с реально некорректными бинарными данными. Вместо ожидаемого поведения — «поймали ошибку и пошли дальше» — процесс просто разваливался, происходил жёсткий обрыв выполнения. Причём выглядело это именно так, будто PG_CATCH вообще не выполняет ту роль, которую я от него ожидал. В этот момент стало понятно, что дело не в мелком баге и не в неудачном тесте. Проблема была глубже — в самой ментальной модели того, что такое исключения в PostgreSQL. И чем дальше я начинал разбираться, тем яснее становилось, что внешнее сходство с исключениями из Java или Python здесь крайне обманчиво. Оказалось, что при ошибке в PostgreSQL меняется не только поток управления. И вот тут начинается совсем другая история, о которой я расскажу в следующем посте. А у вас было такое, что знакомая на вид абстракция вела себя совсем не так, как вы от неё ожидали?