Yeah, in my personal apps I call the previously registered default uncaught exception handler from my own. That's why users still get the force close option. Doing a network call beforehand in the same process doesn't work well. If you wait you can get situations where there's an ANR as well as the pending force close and all sorts of bizarre stuff. If you do it in a different thread and don't wait, then the force close kills your thread before you send the majority of the time. I've tried both.
There are a couple rare cases where I don't pass the exception on to the default handling. I hash the stack trace, compare it to a white list of known harmless exceptions, and don't pass the exception on if it matches one of them. This is only good with a very small subset of exceptions, however. I think I have like an exception or two from Quattro and Millennial Media ad Networks in there, for example. I hate using buggy ad networks, but they pay way more per click than AdMob. Most exceptions you can easily wrap in your own code anyway. These were getting thrown from threads I don't even start, I think. At a company where I work they exit the process and restart, but that adds all sorts of other complications, like restoring state on your own and making sure you don't get stuck in an endless loop if the app dies immediately again. If you are restarting over and over, then obviously it is time to use the original handler, but that's annoying to detect. > use Thread.setDefaultUncaughtExceptionHandler() to > eliminate the force-close dialog and deal with the unexpected > exception myself, such as logging it to a server. This does not > require a remote process. I definitely don't recommend trying to keep using the process for anything user facing after an unhandled exception in general. I've tried that and it just doesn't work reliably. Think about it, how is an activity or UI going to run if the exception killed the loop in the main UI thread that processes messages or something like that? Only ever eat the exception if it is something you've reproduced on your own machines and checked that the process isn't hosed. Most of the exceptions I get reported aren't something I can reproduce, unfortunately. I test on all the devices I can get my hands on and lots of emulator images. We're not talking about common exceptions here. > If the user hits the report button, the crash information will > be available through market feedback. The official Android reporting sucks. It is only on the latest versions and requires Market. It requires a double opt-in button press each time, so users hardly every do it, and yes I have numbers to prove that. It would have been much better to have an opt-out of sending stack traces when a user activates or upgrades to a new Android version that supports it, or when they install an app, and then an opt-in every time for sending additional, potentially more private information. Stack traces would still get sent if the user is lazy and hits force close and doesn't care either way. Something like that. What good is having all that information when hardly any users actually send it? It's fine if they don't send for privacy reasons, but they are not sending because the process is badly implemented and a pain in the ass for the user. > Er... fix the force close in your app...? :p There are unfixable ones in the Android platform, unfortunately. One particular one thrown by ViewGroup.offsetRectBetweenParentAndChild can't even be wrapped by my code. See this thread: http://groups.google.com/group/android-developers/msg/d378a3dc1b467b44 There are also ones in libraries I use or used, like Millennial Media and Quattro advertising as mentioned above. I suppose I could decompile their libraries, fix their bugs, and recompile. Reporting the bugs to them was about as useful as reporting Android bugs on b.android.com, which we aren't even allowed to do for anything but the latest Android versions nowadays anyway, which shows how completely out of touch that process is with the bugs developers have to work around every day. There are also lots of issues that might not be worth fixing as well. All phones, but Droids especially, can get corrupt databases on upgrade even though my DB code matches the official tutorials, for example. Spending time to account for that might help so few users, however, that it would be better for me to write a feature that would help much more users instead. Too bad the platform is so unreliable that even stuff based on the official samples sucks when put out in production and gives your users force closes. On Nov 11, 4:14 am, Kostya Vasilyev <kmans...@gmail.com> wrote: > The default Android "force close" dialog is displayed by the default > uncaught exception handler. > > If you replace the uncaught exception handler, make sure to call the > previous uncaught exception handler from yours, presumably after writing > / sending the exception information. > > So you can have the best of both everything: your own logging for > uncaught exceptions, and still leave the user experience unchanged. > > Regarding "corrupted process" - in some languages that are executed > directly by the CPU, it's pretty easy for application logic errors to > produce heap corruption, such that allocating memory in the exception > handler (for formatting the error message, for example) would crash again. > > Java is different, much safer, in this regard: you get exceptions > (IndexOutOfBoundsException, NullPointerException) instead of a possibly > corrupted heap. > > Therefore, there is a much better chance that the exception handler code > can run from start to finish without crashing itself. > > -- Kostya > > 11.11.2010 3:17, William Ferguson пишет: > > > > > Sorry, I may have muddled several concepts here .. I'll blame lack of > > sleep. > > > I was thinking that a RuntimeException force closes an app and that > > there is limited opportunity to capture the failure (pre Froyo) before > > the app is destroyed. > > > 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. > > > 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? > > > On Nov 11, 9:56 am, Mark Murphy<mmur...@commonsware.com> wrote: > >> Your strategy only makes sense if you feel that your "failed process" > >> will be able to successfully do IPC to start a service to report the > >> exception and *not* successfully be able to report the exception > >> itself. I am dubious that this is the case. If your process truly is > >> failed, neither will work. I think both will work, in which case why > >> add the overhead and complexity? > > >> In the end, though, this isn't a huge deal...*if* your proposed > >> crash-reporting service isn't running all of the time. Saying there's > >> a 2nd process briefly is one thing -- having a long-lived service > >> chewing up a 2nd process is another matter entirely. We still have too > >> many devices with too little RAM to be using that sort of technique > >> today. > > >> -- > >> Mark Murphy (a Commons > >> Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > >> _The Busy Coder's Guide to Android Development_ Version 3.2 Available! > > -- > Kostya Vasilyev -- WiFi Manager + pretty widget > --http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
