I'm working on a managed package in which our customer (the company that asked us to develop the package) runs into certain exceptions in edge case UAT scenarios (e.g. API has gone bonkers for 10 minutes). We're trying to debug but this is currently stymied by the fact that we're catching certain known exceptions to display messages about them to the UI. However this results in the stack trace getting lost (because getStackTraceString()
is obfuscated in installed managed package code).
We'd neglected to set up this package version with an e-mail to receive exceptions, so we will do that on the next release. But the the exceptions won't arrive unless we leave them unhandled. And if we leave them unhandled we cannot give them a friendlier failure experience. (e.g. "We experienced an error creating this order. The developer has been notified.")
What if we catch the exception to display an error message in the UI, but then pass it to a Queueable to throw it again in another transaction? (In other words, return an error to the UI synchronously and then throw the exception async.) Will that maintain the integrity of the stack trace and allow us to receive exception e-mails?
Otherwise, any other ideas for patterns that allow us to see the full stack trace without making the subscriber feel like they just ran into a brick wall?