How to debug an unhandled exception

Just wanted to let everyone know that we've reproduced this in house and have a ticket to address it.

jim_m_58 fair enough and agreed on all points :).

They are to be used sparingly, but can be useful, especially when writing new code. It's a "do what works best for you at the time" thing. Just one of the tools in the toolkit. :)

So what about the real point of this thread? Why isn't the stack always shown in the simulator with exceptions? Without jumping through hoops with try/catch blocks? It's a bug, and I think we all hope it gets fixed soon. var val; try { val=Application.Property.getValue("badkey"); } catch(e) { val=defaultValue; } "badkey can happen in development due to a typo, and catching it means fixing it faster. I would argue that catching that exception actually means fixing that typo slower, or even never. To reiterate: If you're just using exceptions to guard against typos or other kinds of mistakes, I would argue that's a bit sloppy. Let me elaborate: 1) Ideally, to catch that kind of mistake (typo or copy/paste), you would simply test the code (without try/catch) and let it crash so you could find it and fix it right away. And if you don't find it, your users will pretty soon, hopefully. 2) If you get used to placing try/catch blocks around every possible source of coding error, then you run the risk of hiding bugs. In your example with "badkey" you're not letting the program crash, nor are you logging the existence/source of an error. You're simply using the default value for "badkey" which means that you might never even know there's a problem. Now your app has a setting that can never change, although I'm sure that was not in the design.... 3) The reason you can't do 1) is because the stack trace isn't being printed for unhandled exceptions.... There's a school of thought which says certain kinds of (programmer) errors should just cause a crash, so they can be identified and fixed right away. This includes omitting null checks where a function was designed to always take a non-null object. For example, in Monkey C, if you pass in null where a non-null object was expected, in most (or all) cases, the app will crash/terminate instead of failing gracefully (e.g. "null.find("abcd")" will crash instead of returning null). After all, why do apps crash? Why does Monkey C have errors which cannot be handled? Surely a language/OS/architecture could be designed with the goal of having few crashes. But one reason for crashes is to let coders know they've made a serious mistake. Counter-example: Suppose I put try/catch around all my possible sources of error and log using System.println. Say I don't test all those sources of error. Now that I have handled exceptions everywhere my users may never see those problems -- they'll just have a subtly malfunctioning app. I think try/catch is great when you are expecting a recoverable or expected error due to bad user input or running out of resources, or similar circumstances outside of the dev's control. On a device with a bigger screen it would be fine to use it to display/log the exception, notify the user nicely and exit the app gracefully. In general I wouldn't use it to guard against simple kinds of programmer error, like typos or copy/paste errors. Better to leave that kind of exception unhandled, IMO.

"badkey can happen in development due to a typo, and catching it means fixing it faster. I have common settings code that's used in many things, be they production or a brand new project. In the real version, I display the actually key using println so I know exactly what to look at. Just getting an exemption with a stack trace could actually take longer :)