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<[email protected]> 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 [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
