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.
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.
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.
> Section: Class 72 - Snapshot Failure > # (class borrowed from Oracle)
Nothing from SAP / ABAP ? :^)