It has been a while since my post about Postmortem Reports via email and since then I have upgraded it, commented more on it and fixed a few issues as well. The class now protects against a null exception and uses the application label instead of the activity title in the subject. The class also unregisters itself on finalize as well as protects against sending multiple reports for a single exception if you have several activities active and each has their own handler registered. I am also happy to report that people are willing to send you debug reports. I do not receive more than a handful, but I only need one or two in order to figure out what is going on and fix it. I also can tell how serious it is depending on how frequently I get a report about it. I even get reports from people using a pirated version of my paid apps.

I modified the original post…

Now to show you how easy this class is to use.  First, you want to create a field in your activity class to create an instance of this postmortem reporter.  Once you’ve done that, first call it’s run() method during your activity’s onCreate() method.  While calling run() is not critical to it’s operation, it is good practice to do so as a fail safe to protect against generating an exception and the email Intent fails to occur.  Failure to send the email report are rare, but it does occur.  Second, you call the static method Thread.setDefaultUncaughtExceptionHandler(myDmgRptField) and pass in the postmortem reporter field.  Anything after that line of code will be “protected” by the damage report mechanism and will remain in effect until the class is destroyed. That’s it!

since I added a convenience method called initialize() that can be used in place of what I struck out in the quote above.

If you have several Activities in your app, you will want to place a PostMortemReportExceptionHandler object in each Activity. The reason you want one in each Activity is not for extra protection, but for additional debug information not easily gathered in any other way. An Activity stack trace is created by querying the chain of debug handlers currently in effect. The Activity’s class name and current title will appear in the stack. Additionally, if getCallingActivity() returns a non-null value, the Intent information supplied by the caller will also appear in the stack. The Activity stack information may help retrace the steps taken to encounter the exception being reported (which can get pretty complicated sometimes). The debug report will only be sent once no matter how many handlers you have in the chain.

I thought about changing the Activity reference to use a WeakReference instead of a standard variable, but have decided to leave it as is. The handler should be around as long as the Activity, getting destroyed when the Activity is destroyed so there’s no real pressing need to make it a WeakReference as their life cycles are almost exactly the same.

In the months since I started using this class in my own apps, I have seen a noticeable increase in quality and fewer negative comments and low ratings based on strange exceptions I could not duplicate in house. Android phones are not perfect and each device manufacturer and carrier introduces the possibility of introducing bugs and quirks that require attention. Please note that I have only found a couple of instances where this was a problem… but when it does occur, it is very difficult to correct without some way of reporting what is going on.