A common pain point in most GUI frameworks is the hidden stack traces. When we have an app in production we get occasional emails from crash protection which are cryptic and hard to figure out. They usually start with the EDT loop and make no sense.
The reason for that is
callSerially(). When we have code that invokes
callSerially we essentially lose the previous stack trace. So your stack trace would look roughly like this:
java.lang.RuntimeException: at com.mycompany.MyClass.myMethod(MyClass.java:400) at com.codename1.ui.Display.edtLoopImpl(Display.java:1166) at com.codename1.ui.Display.mainEDTLoop(Display.java:1070) at com.codename1.ui.RunnableWrapper.run(RunnableWrapper.java:120) at com.codename1.impl.CodenameOneThread.run(CodenameOneThread.java:176)
For most cases you can just fix line 400 of
MyClass so it won’t throw an exception but you might be hiding a worse bug. Lets say that line fails because it expects a specific condition to exist in the app and that condition isn’t met. A good example for this would be logged in users. Lets say your app expects the user to be logged in before
myMethod is invoked but for some reason he isn’t.
That means the real bug occurred elsewhere probably in the area of code where
callSerially() → myClass.myMethod(; was called. Lets say you looked over the entire body of code and you have suspects but can’t tell which part is at fault. Narrowing this down would help…
Display.setEnableAsyncStackTraces() comes in. When set to true it creates a “fake” exception for every
callSerially if there’s a “real” exception thrown within the
callSerially it uses this “fake” one as the cause. That means you will be able to see the cause for a specific bug when this is enabled.
Notice that this API is potentially prohibitive in terms of performance. As such we recommend that people don’t turn this on by default. You can include this as a user configuration or use it in debug builds.