All supposedly true.
I was catching all caught and uncaught RuntimeExceptions.
ArithmeticException is a subclass of RuntimeException, so it SHOULD
have stopped at the point of the throw.
It did not. It stopped later, when a RuntimeException was thrown with
the original ArithmeticException as its cause. I believe this is a
bug, and the correct behavior is as you describe.
Breaking on ArithmeticException explicitly, DID break. I'm guessing
this is an interaction between the VM and JDWP implementations, though
I didn't experiment to figure out the scope of the issue.
Thanks for the pointer to dalvic/docs/debugger.html. I'd observed the
behavior from merging return statements, and understood it; it's nice
to see it confirmed in writing!
I was trying to avoid getting too detailed in my explanation -- but
it's also good to have all that detail out there for the broader
audience.
I'm not sure if you were aiming your explanation at me, or augmenting
my explanation to the OP. If the former, perhaps I should mention that
my background in compilers, runtimes, and debuggers goes back to the
1970s. I maintained and implemented two Lisp systems at MIT, working
with Guy Steele (author of the Java spec), among others. I've done
stuff with on-the-fly byte-code generation in Java, JVMTI, and other
alphabet soup I can't recall.
So maybe it'll carry some weight when I say: nice job on explaining
and clariying the details I glossed over.
Overall, I've been quite impressed with the JDWP implementation. I
have been pleasantly surprised at how few deviations there have been
between debugging on Dalvik and JVM.
Completely OT, but you might appreciate this: Thanks to the folks
behind and magicandroidapps.com, I have ITS -- the PDP-10 operating
system that MacLisp ran on at MIT in the 1970's -- running on my Nexus
One. I've recently acquired a snapshot of the necessary ITS
directories, and hope to get MacLisp up and running on my Nexus One --
faster than on the original systems!
On Feb 10, 7:36 pm, fadden <fad...@android.com> wrote:
> On Feb 9, 7:09 pm, Bob Kerns <r...@acm.org> wrote:
>
> > You may not be seeing what you want because you stop too soon, before
> > it's really created the exception.
>
> The debugger stops at the point of the throw. There is no exception
> variable to examine because there's no exception variable in the
> source code for the debugger to refer to.
>
> The exception object is passed to the debugger when the "exception
> happened" event is sent up, so it's free to display it however it
> chooses to. I expect different debuggers deal with this in different
> ways, but so long as they're using JDWP to talk to the VM they all get
> the same set of information.
>
> (FWIW, you can connect any debugger you like through DDMS. It's
> probably easiest to make sure there's only one person talking to the
> VM at a time if you close Eclipse and use the stand-alone "ddms"
> command. I've used "jdb", IntelliJ IDEA, and a couple others.)
>
> > I didn't paste it into this message, but I did look at what was in the
> > exception, I just clicked on the little triangle to expand. It showed
> > the message ("Divide by zero"), and also showed that the stacktrace
> > field hadn't been filled in yet (which I expected).
>
> The stack trace elements are populated on demand. Since most
> exceptions are never displayed, it's inefficient to go through the
> trouble of formatting a nice stack trace. There's an array of int[]
> hiding in there that has the actual info.
>
> > But, I do spot one anomaly here: I have it set to break on
> > RuntimeException. ArithmeticException is a RuntimeException, but it
> > didn't break. It didn't break until it tried to rethrow it, further up
> > the stack.
>
> Make sure you're trapping both caught and uncaught exceptions. An
> exception is considered "caught" if there's a "finally" block anywhere
> below it, and there are dx-generated "finally" blocks in all
> synchronized methods. You end up breaking on a lot of stuff you don't
> care about, but sometimes it's the only way to really catch the
> exception.
>
> Some notes about the debugger can be found in the source tree in
> dalvik/docs/debugger.html
> http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=d...
--
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
