Forgive the lengthy response. You probably know all of this already and
we're just getting hung up on nomenclature...

Faber Fedor wrote:
>     It'd be the top line in the stack trace, after the exception
>     name/message.
> 
> 
> Are you talking in DDMS?  I can't get threads or the heap working in there.

I'm talking about the stack trace. The exception. Use adb logcat, DDMS,
Eclipse, I don't care -- it's the place that tells you "this thing went
blooey" and shows you all the methods, from the particular line that had
the exception up the call stack, where you were at the time.

> And while I am ActivityThread.performLaunchActivity, the exception gets
> thrown.

That is probably the bottom of the stack trace. I'm interested in the top.

For example, from
http://www.devdaily.com/java/edu/pj/pj010009/pj010009.shtml

      java.io.FileNotFoundException: fred.txt
              at java.io.FileInputStream.<init>(FileInputStream.java)
              at java.io.FileInputStream.<init>(FileInputStream.java)
              at ExTest.readMyFile(ExTest.java:19)
              at ExTest.main(ExTest.java:7)

In this case, ExText.readMyFile is the line that triggered the
exception. However, the exception itself occurred two calls deeper, in
the bowels of java.io.FileInputStream's constructor.

For many exceptions, this isn't that big of an issue -- you can think of
ExText.readMyFile as being "where the exception occurred".

For NullPointerException, though, it really helps to know the the line
in which the exception was raised -- the first line reported below the
exception.

Why?

Because *that's* the line that attempted to access a null object.

So, rolling all the way back to your code, if the first line in the
stack trace below the exception is the line you cited
(map.getOverlays().add(new SitesOverlay(marker));), then you know that
*that line* attempted to use a null object, meaning that either map or
map.getOverlays() returns a null. If, however, there are other lines
between the exception and the above-quoted statement, that means your
code may have *passed in* a null, and so either marker is null or
somehow SitesOverlay is having problems and can't be instantiated.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com
Android Training in Sweden -- http://www.sotrium.com/training.php

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to