Complete
over 4 years ago

WERETECH-6805

This was addressed in CIQ 3.1.1.

How to debug an unhandled exception

On a fresh Eclipse install on macOS High Sierra with recommended settings (several example apps do build and run), I can't seem to get a strack trace after an unhandled exception (aka app crash). Without that information, it's pretty much impossible to debug an app, so I guess I just missed some setting.

What did I miss?
Former Member
Former Member
  • I'd have to agree that it'd be nice to have the debugger automatically always include the stack trace in unhandled exceptions. I had never actually used the try/catch block in MonkeyC until just now and it was interesting how you can display the stack trace there. I've never understood why sometimes I do and sometimes I don't get the stack trace by default in the simulator. Seems bizarre to me that it doesn't always show it and thought I just had something wrong in my configuration. I generally don't use exception handling as I'd rather have the code be bullet proof, rather than dealing with unexpected exceptions. Unless you are calling a function or method that explicitly states it can cause and exception, exception handling seems like a bandaid fix. If you have bugs that can cause exceptions, you're probably going to have more bugs in the exception handling itself. And with a limited memory system like this, better to just get the code right to begin with.
  • It’s a bug in the plugin that had been reported. My occasional work around for obscure crashes s to run the crashing code on a device and read the log which does have a stack trace!
  • Yes, with the catch block -- combined with e.printStackTrace() -- I perfectly see that foo() returns a type that cannot be converted. It just would be nice to have this exception also on console instead of the more general Unhandled Exception, that would make debugging a lot easier. Because I guess it's very complicated to add try-catch blocks on all entry points of my application, as most functions are called from system in case of events like timer, key press, etc.so there is no global entry point like the good old WinProc in Win32 anymore :)
  • Using this code: function initialize() { WatchFace.initialize(); var fun=method(:foo); if(fun.invoke()) {System.println("true");} } function foo() { System.println("in foo"); return ""; } I don't see any problem/exception with 3.0.8 and a 645 target. I'd expect the "if" to be true (as it's not "false") The output is: in foo true Is there something else in your code you didn't say, like different classes or something? update: Ok, I missed the "!" and see it now.... But with a try/catch, you see it: try { if(!fun.invoke()){System.println("true");} } catch(e) { System.println("e="+e.getErrorMessage()); } e=UnexpectedTypeException: Expected Number/Boolean/Long, given String It does seem that you should see the exception without the try/catch though
  • The problem still seems to exist. I have a very small test cases that results in an Unhandled Exception: var m = method(:foo); if (!m.invoke()) { } function foo() { return ""; } There should be an Exception like "Cannot cast string to boolean" in the invoke() line instead. I'm using SDK 3.0.8 for this test case.