3

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?

0

1 Answer 1

2

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.

2
  • Right, I expect the stack trace as seen from Apex to remain obfuscated. I know that an unhandled exception in a managed package normally generates a NON-obfuscated e-mail to the address designated for managed package errors. I'm curious if the ability to receive that e-mail without obfuscation would survive if that Exception is passed to a Queueable and then thrown there. I guess I will just have to find out...
    – Charles T
    May 19, 2018 at 0:21
  • @CharlesT try it out, let me know. I'd love to know the results.
    – sfdcfox
    May 19, 2018 at 1:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .