3

I know this has been discussed before but all of the threads are several years old. I couldn't find a finite answer and also I am trying to find out if anything has changed since.

I am trying to figure out what is the best way to handle exceptions in a managed package where I can notify myself about them without the customer having to take action. In other words be proactive rather than reactive.

Ideally what I am looking for is the getMessage() and getStackTrace() methods on the Exception class.

I've been browsing through SE and it appears it won't be as straight forward as writing apex code in your own org.

Errors within managed packages are suppressed. You will need to raise a case with SF to get the logging turned on for managed packages. They will only enable the logging for a certain amount of time.

We have the error stack traces stored into a custom object, but even using the subscribers tab log in doesn't unmask the stacktrace; just says (namespace).

As of right now has any of this changed? Is it possible to capture the stack trace and store it in a custom object/email it to myself/store it to an external API?

What do you guys do with your managed packages in order to debug any errors?

As a last resort - if I throw an error can the user in the org see the stack trace and perhaps provide it to me?

Sources: link1, link2, link3, link4

Improve this question

1 Answer 1

Reset to default
5

As described in your link1, full stack trace information is only available when you login to the org via the LMA. And this option is only available if your app has passed a security review. So getting detailed information forwarded automatically is problematic.

There is this Handling Apex Exceptions in Managed Packages mechanism that you could experiment with, but while we have it turned on in some packages, I suspect extra configuration is needed to make it work reliably, as for a package I work with we don't get these emails.

Salesforce have started using Platform Events to publish error conditions. While EventBus.publish always counts as DML, for "Publish Immediately" events the event will be delivered even if the transaction rolls back. (Using your own error logging table typically doesn't work because of the rollback.) So you perhaps could arrange to notify yourself, but with just simple messages as you won't be able to get hold of the stack trace data missing.

But some exceptions such as governor limit ones can't be caught in Apex so you can't handle those anyway...

So in summary, build your app so it doesn't break, because when it does break in production use, you'll be getting a support call from your customer with limited information as a starting point, and will then have to login through the LMA to get enough detailed logging to track the problem down.

Will be delighted if someone posts a better answer here...

Improve this answer
5
  • 1
    This is a stellar answer. Thank you for posting it. I wish I could upvote it twice.
    – Vivek M. Chawla
    Commented Apr 7, 2021 at 22:14
  • Thanks for the detailed response. I could use a trigger on the platform event to insert the error so even if there was a rollback I can insert the error separately. Does this sound like a good idea? What else did you have in mind when you mentioned that I could use the platform events to notify myself? Is it by sending out an email? I really need to be able to see the stack trace in case there is an error. If the user gives me access through LMA to their org will I be able to see the stack trace immediately or will I need to do something else as well?
    – Arthlete
    Commented Apr 8, 2021 at 4:07
  • 1
    Hi @Arthlete, Yes you are right about the trigger but in theory the Platform Events can be subscribed to off platform (CometD) but I don't know if that is practical. Once a user has applied "Grant Account Login Access" to you ("Xyz Support") you will get stack traces but only on the session you create through the LMA i.e. you have to interactively debug to get that info. You will also see governor limit exceptions this way.
    – Keith C
    Commented Apr 8, 2021 at 7:39
  • Thank you so much for circling back to respond. I really appreciate sharing your experience as I am completely new to this. I suppose that I will need to hire a really good QA and heavily rely on them before I release the app.
    – Arthlete
    Commented Apr 8, 2021 at 16:39
  • Well @Arthlete, you can do a lot with Apex unit tests working at the story level and running from a Continuous Integration server. And if you build in enough APIs then QA can focus on automation for regression testing with manual testing being a smaller part of the job.
    – Keith C
    Commented Apr 8, 2021 at 16:43

You must log in to answer this question.

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