Зачем строить логику на исключениях, если Вы можете проверить существовании

сущности в базе?

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

Как обрабатывают — логируют или смотрят в сентри такие исключения и ищут как они туда попали... фиксят

Затем, что код, построенный на констреинте работает быстрее и без возможности рейс кондишена. Проверять пользователя селектом - ебанина

Ну не совсем, рейс кондишен есть (гонка есть и есть проигравший просто стэйт констстентным останется)

Констрейнт тут не помешает точно, но как его обрабатывать (если вообще без селекта) если их несколько и выводить пользователю? Парсить исключение выброшенное БД ?

На уровне обработчика, который общается с дбал слоем

Ну так он не выведет в удобном формате какое поле дало сбой и т.д. Парсить?

Парсить что?

sql ошибку, чтобы понять какой констрейнт вышибло и выдать пользователю понятное сообщение

catch?

мы ее поймаем, но как мы определим, что мы поймали что телефон не увникальный или ИНН ?

instanceof?

Страшную вещь скажу - обычно всем насрать. Просто кидаешь конфликт и пусть клиент сам проверяет

Он хочет имя констрейнта получить

Я бы понял, если мы сначала проверили селектом , а рейс кондишн выводили "как всем насрать". Т.е. мы бы покрыли номральным сообщением и ответом 99% случаев.

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

Я тоже так делаю

Типа у тебя ну пути до респонса объект юник констреинт эксепшена превращается в юзер алреади экзист и ок. Хочешь эйзер вернуть вместо эксепшена, ок, тоже никто не мешает. А там контроллер сам решит че с этим делать и как рендерить