On Wed, Nov 10, 2010 at 7:17 PM, William Ferguson <[email protected]> wrote: > But if using Thread.setDefaultUncaughtExceptionHandler() actually > stops the force close then there is opportunity to dispatch the crash > report since the app won't be destroyed. Whether the crash dispatch > happens in the app process or another process is irrelevant.
Correct. If you catch the unhandled exception yourself, none of the automated stuff (force close dialog, etc.) kicks in. It is up to you how to deal with it. I'd always try reporting it, assuming you're hooked up to a system to do that. After that, the strategy is up to you: just continue along, finish()/stopSelf() the offending component, System.exit() to blow away the process, etc. Similarly, it's up to you how you inform the user about what transpired (dialog, toast, nothing). > And yes, I was only imagining having the 2nd process exist briefly. > Something like an IntentService solely tasked with dispatching the > crash and handling disconnection and other dispatch failures. But that > doesn't seem as relevant now. > > Am I back on track? Yup. And you probably weren't all that far off the track originally -- I was overreacting. I too am short of sleep. My apologies. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.0.1 Available! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
