3 ms·

In my case I assign each error message a unique code and prefix the message with the name of the function. Makes it very easy to find where things went wrong.

jareklupinski 5y ago
how do you keep from colliding with an existing code when writing a new one, just search the repo for its use before committing or...?
- RedShift1 5y ago
  All codes are kept with a constant name prefixed with E_ in one file.
  - agent327 5y ago
    That must be a joy to edit. "Oh, a new error. Time to recompile the whole system!"
    - sa46 5y ago
      It's not an uncommon pattern: https://github.com/postgres/postgres/blob/master/src/backend/utils/errcodes.txt https://github.com/postgres/postgres/blob/master/src/backend...
      - agent327 5y ago
        I wasn't making any statement about how common it was, only about how impractical it was. And soon enough you'll find that it is just more convenient to reuse a few error codes here and there, and soon enough applications just report "error -1: resource failure" or "internal failure" or some other meaningless thing. Far better to just return a string.
      - jareklupinski 5y ago
        > Section: Class 57 - Operator Intervention > # (class borrowed from DB2) > Section: Class 72 - Snapshot Failure > # (class borrowed from Oracle) Nothing from SAP / ABAP ? :^)
tialaramex 5y ago
For web services, and similar with errors that users see, but where the backend lives closer to the programmers, I very much endorse: 1. Mint a UUID for each specific occurrence of an error the user is getting informed about. 2. Write the whole stacktrace to a log, with the UUID and any other context that seems important. 3. Show the user the UUID, but in smaller type than any advice they might actually be able to use themselves like "0123456789 is not an email address" or "This service is not available to users in your group, juniorAssistants". 4. Ensure front line supports know they need this UUID to pass errors on to anybody who can do more than recite the help text. Users will take photos of screenshots, they'll attach them to email as Excel spreadsheets with an embedded image, but they can get you the UUID and that shortcuts so much of the debugging process in many cases, while not giving them a bunch of debugging output that: * Might be non-public by GDPR type rules, legal privilege or just common sense. * May contain valuable commercial secrets, one man's obvious class hierarchy is another man's secret sauce product design. * Is long and complicated and will not survive being captured to a screenshot, scaled, pasted into a Word document and then photographed with a phone, which your users actually will do for some reason.

jareklupinski 5y ago

how do you keep from colliding with an existing code when writing a new one, just search the repo for its use before committing or...?

RedShift1 5y ago
All codes are kept with a constant name prefixed with E_ in one file.
- agent327 5y ago
  That must be a joy to edit. "Oh, a new error. Time to recompile the whole system!"
  - sa46 5y ago
    It's not an uncommon pattern: https://github.com/postgres/postgres/blob/master/src/backend/utils/errcodes.txt https://github.com/postgres/postgres/blob/master/src/backend...
    - agent327 5y ago
      I wasn't making any statement about how common it was, only about how impractical it was. And soon enough you'll find that it is just more convenient to reuse a few error codes here and there, and soon enough applications just report "error -1: resource failure" or "internal failure" or some other meaningless thing. Far better to just return a string.
    - jareklupinski 5y ago
      > Section: Class 57 - Operator Intervention > # (class borrowed from DB2) > Section: Class 72 - Snapshot Failure > # (class borrowed from Oracle) Nothing from SAP / ABAP ? :^)

tialaramex 5y ago

For web services, and similar with errors that users see, but where the backend lives closer to the programmers, I very much endorse: 1. Mint a UUID for each specific occurrence of an error the user is getting informed about. 2. Write the whole stacktrace to a log, with the UUID and any other context that seems important. 3. Show the user the UUID, but in smaller type than any advice they might actually be able to use themselves like "0123456789 is not an email address" or "This service is not available to users in your group, juniorAssistants". 4. Ensure front line supports know they need this UUID to pass errors on to anybody who can do more than recite the help text. Users will take photos of screenshots, they'll attach them to email as Excel spreadsheets with an embedded image, but they can get you the UUID and that shortcuts so much of the debugging process in many cases, while not giving them a bunch of debugging output that: * Might be non-public by GDPR type rules, legal privilege or just common sense. * May contain valuable commercial secrets, one man's obvious class hierarchy is another man's secret sauce product design. * Is long and complicated and will not survive being captured to a screenshot, scaled, pasted into a Word document and then photographed with a phone, which your users actually will do for some reason.