Descriptive body for errors

[twiddler]

I am trying to catch exceptions when inserting duplicates that violate a UNIQUE constraint. Node prints the exception as

… caused DatabaseError: target: ….-.primary: vttablet: rpc error: code = AlreadyExists desc = Duplicate entry 'foo' for key 'SomeTable.someAttribute' (errno 1062) (sqlstate 23000) (CallerID: …): Sql: "insert into SomeTable(someAttribute) values (:vtg1 /* VARCHAR */)", BindVars: {REDACTED}

console.log(e) gives me

{
  status: 400,
  body: {
    message: 'target: ….-.primary: vttablet: rpc error: code = AlreadyExists desc = Duplicate entry \'foo\' for key \'SomeTable.someAttribute\' (errno 1062) (sqlstate 23000) (CallerID: …): Sql: "insert into SomeTable(`someAttribute`) values (:vtg1 /* VARCHAR */)", BindVars: {REDACTED}',
    code: 'UNKNOWN'
  }
}

I can parse that message with a regex to extract the code and everything, but I think it'd make more sense to have a few more fields that digest that information already (errno would probably be the most helpful, at least for my use case).

One could also take that a step further and introduce more classes that derive

database-js/src/index.ts

Line 15 in f62005c

export class DatabaseError extends Error {

but I suspect that might get out of hand quickly. I just checked out the MySQL error reference and it's enormous.

Also code: 'UNKNOWN' seems a bit odd, unless it does not describe any of code, errno or sqlstate.

[twiddler]

I'd like to reiterate the necessity for this since parsing the error message is not a reliable solution: Just recently, the error messages changed, and as a consequence my regular expression did not match errno and sqlstate.

Luckily that code had not hit any production environment yet, but my app is evolving in a way that I will have to handle database errors more and more. I'd highly appreciate a DatabaseError.errno: number field that I could rely on.

Thank you. 🙏

[hiSandog]

The report is specific enough that it could probably be turned into a small failing test for “Descriptive body for errors”. I would try to assert the exact behavior around UNIQUE rather than only checking that the command or UI path no longer errors, so the test guards the intended fix.