On Feb 14, 2:11 am, Rab <m...@wizzy.co.uk> wrote: > It almost looks as though the framework handles the exception, unwinds > the stack and then reports the issue.
Almost. Eclipse is configured to break on uncaught exceptions. Your code is running in an app framework that catches the exception and then re-throws it, so Eclipse doesn't actually break until the re- throw (at which point the program has continued well past the site of the original exception). > How can I ensure that the exception halts the debugger at the point > that the program crashed (i.e. my function appears as a caller in the > call stack), or otherwise backtrack to the point in my code that broke > using the debugger. By the time it breaks, the state is lost. You need to tell Eclipse to break on *caught* exceptions as well as uncaught. Doing this for all exceptions is not a good idea -- a lot of exceptions get thrown around during class loading -- but you could, for example, configure Eclipse to break on caught NullPointerExceptions and probably not break too many times before you hit a "real" exception. Note this only applies to the main (UI) thread. Any worker threads you create will be started without an exception-catcher farther up the stack, so debugging will work normally. For other fun facts, see: http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/debugger.html;hb=HEAD (skip down to "Known Issues and Limitations") -- 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
