Managed Package: Catch exception and then re-throw asynchronously?

Question

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?

Answer 1

I don't have a managed package I can test with, though I suspect the stack trace will remain obfuscated. However, it certain does send an email and transfers the stack trace correctly:

public class q218635 implements Queueable {
    Exception ex;
    public q218635(Exception e) {
        ex = e;
    }
    public void execute(QueueableContext context) {
        throw ex;
    }
}

---

Execute Anonymous:

void a() {
    b();
}
void b() {
    c();
}
void c() {
    d();
}
void d() {
    Integer i = 0 / (Integer)null;
}
try {
    a();
} catch(Exception e) {
    System.enqueueJob(new q218635(e));
}

---

Resulting log:

15:47:49.3 (7637878)|EXCEPTION_THROWN|[7]|System.NullPointerException: Attempt to de-reference a null object
15:47:49.3 (7670163)|FATAL_ERROR|System.NullPointerException: Attempt to de-reference a null object

AnonymousBlock: line 11, column 1
AnonymousBlock: line 8, column 1
AnonymousBlock: line 5, column 1
AnonymousBlock: line 2, column 1
AnonymousBlock: line 14, column 1
AnonymousBlock: line 14, column 1

Again, I don't have a way to verify how much stack you'll see, but the exception does appear to be fully transferable to a new process while still showing the original stack trace.