Как правильно отправить sql ошибку клиенту?

Question

[WhatIsHTML]

Всем привет. Под рукой NodeJs, Express, PostgreSql, pg-promise
Возник вопрос о том, как правильно отлавливать и отправлять sql ошибку на клиент.
Если SQL запрос не удался, например из-за того, что ключ уже используется, то все ок, получаю ошибку и могу отправить ее на клиент. Но что-то мне подсказывает, что в исходном виде отправлять ее нежелательно и это как минимум не user-friendly. Как по-хорошему это делается? Может есть какие-то npm пакеты, которые парсят код SQL ошибки и отдают читабельную краткую информацию? Или самому разбирать?

В моем случае есть запрос

self.updateInfo = function (user) {
   return db.query("UPDATE users SET name=${name}, username=${username}, email=${email} WHERE (id=${id} AND activated = true) RETURNING *;", user);
    }

В контроллере обычный then/catch

userSQL.updateInfo(user).then(function (newUser) {
    response.json({
      message: "user updated",
      data: newUser
    });
  }).catch(function (error) {
    handler.error(response, 400, error);
  });

Пример SQL ошибки которую получаю

{"message":{"name":"error","length":305,"severity":"ОШИБКА","code":"23505","detail":"Ключ \"(username)=(test)\" уже существует.","schema":"public","table":"users","constraint":"users_username_key","file":"nbtinsert.c","line":"434","routine":"_bt_check_unique"}}

Answer 1

[Melkij]

А зачем вообще отправлять ошибку запроса на клиент?
Ошибке запроса самое место в логе и только там. Клиенту - HTTP 500 и "извините, не шмогла" написанное любым вариантом какой вам понравится.
Если требуется другое сообщение (или действие) для конкретной ошибки - ловите этот конкретный код ошибки. На допустимость логина обычно проверяют предварительным запросом, в апдейт on conflict пока не завезли. Плюс можно хапнуть advisory lock для устранения race condition и закатать всё в одну хранимку чтобы сэкономить на планировщике и сети.

Comments

[WhatIsHTML]

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

[Виталий]

в апдейт он конфликт завезен если делать insert into tablename (pam, pam, pam,) VALUES (1,2,3) on conflict (pam, pam) DO UPDATE....
последнее создаст новую запись иили проапдейтит существующую, по мне удобно.

Answer 2

[d-stream]

Нормальный вариант - не делать селекты, а вызывать stored procedures, которые на базовом уровне проверяют логическую (бизнес) консистентность данных и выводят user friendly отлуп в виде "такой код уже используется", "невозможно списать со счета клиента сумму хх, потому что на его счету недостаточно средств", "для выполнения данной операции недостаточно прав" и все "непредсказуемые" оборачивая в try catch - вываливать уже как 500 или что-то подобное "произошла системная ошибка, сообщите разработчикам. подробности: ...." (ну или писать в лог)