Any idea why the following code crashes the app? It happens in calculateGmt()

by Justin Anderson » Wed, 21 Apr 2010 15:53:15 GMT

Sponsored Links
 First thing I noticed right off the bat is that you aren't checking for the
case where the input can't be parsed to a double...  That throws an
exception and since you aren't handling that that would crash your app.

Second thing I noticed is that hideous @SuppressWarnings thing....  In my
opinion if you need to do that then you need to rethink what you are doing.

Last, but not least, check the logcat output when you get a crash... it will
tell you more about why it is crashing.

There are only 10 types of people in the world...
Those who know binary and those who don't.


Any idea why the following code crashes the app? It happens in calculateGmt()

by Indicator Veritatis » Thu, 22 Apr 2010 06:48:29 GMT

 I'm not seeing enough info for me to run this myself under Eclipse
DDMS and see the exception -- which is probably your best bet for
diagnosing the problem. Or, if it crashes before it waits for user
input, you should use Debug: 1) set a breakpoint by double-clicking on
the bar to the left of the line number in the Java source code editor
2) instead of doing Run As (or ctl-F11 or the corresponding tool),
launch the debugger by clicking on the tool that looks like a bug or
by doing F11 instead of ctl-F11. You can always switch back to DDMS
perspective in Eclipse after that and look in the Logcat output for
the exception.

Or, as either an alternative, or in addition to the above, you might
want to break up complicated lines like

"double val = Double.parseDouble(gmtinput.getText().toString());"

into multiple assignment statements. That will reveal where, for
example, you forgot to actually allocate memory for the result.


Sponsored Links

Any idea why the following code crashes the app? It happens in calculateGmt()

by Indicator Veritatis » Thu, 22 Apr 2010 06:57:11 GMT

 ll good points!

In particular, the OP should have told us what the warning suppressed
really was. It might have been the hint he needed to solve the
problem. Or it might have been just another attempt to suppress the
spurious warning messages from Eclipse -- which sometimes says you
need to Override a method you have already Overriden.

And just to connect a few dots: the easiest way to get to Logcat and
search the output is to switch to DDMS perspective, find the Logcat
tab, bring it to the front and maximize it. Then you can delete the
previous contents of the log and just watch the world scroll by. Or
play around with filters, though that is not necessary for this

It also helps to watch this Logcat output on a known good program run,
so that you can get used to which error message can be ignored.
Unfortunately, even for a program running perfectly OK on the
emulator, we see Java exceptions and other error messages in Logcat.

On Apr 21, 12:51am, Justin Anderson <> wrote:
> >

Other Threads

1. Sending messages from app that would show up in adb logcat?

It would be convenient to send arbitrary strings to this stream so
that I could view them on my computer terminal during adb logcat.




2. Froyo 2.2 on MX51, no GUI on LCD at startup.


Porting Android Froyo 2.2 to a Freescale MX51 based board. Kernel
boots fine, some errors in logcat that I can live with for the moment,
but no GUI. I have seen the penguin on the framebuffer at bootup so I
know the LCD is working.

I also see the Android letters and the blinkering cursor. Then blank.

The complete logcat is:

Anyone with experience willing to help me out with some ideas?

Thanks in advance,


3. Normal-hdpi vs large-mdpi

4. Anti-aliasing filter on AudioRecord?

5. any one have good document on android porting on friendly arm

6. emulator stuck in android logo screen

7. Package Parsing Problem