-
Notifications
You must be signed in to change notification settings - Fork 520
Exceptions #79
Comments
Not really, unfortunately. Java doesn't have a built in way to manage stack traces across threads and our last attempt (#11) caused a lot of OOM issues. As long as you're not thread switching very often, you should at least have a small stack to look at. Not the best answer, but I don't think there's a solution for any Java concurrency library atm. |
Ok, thanks. Can you elaborate on what you mean by thread switching? Maybe I need to change something here. Here is an example stack trace: com.aadhk.billing.c: Error refreshing inventory (querying prices of items). (response: 6:Error) at com.aadhk.woinvoice.util.ca.a(ProGuard:315) at com.aadhk.billing.g.run(ProGuard:719) at android.os.Handler.handleCallback(Handler.java:739) at android.os.Handler.dispatchMessage(Handler.java:95) at android.os.Looper.loop(Looper.java:155) at android.app.ActivityThread.main(ActivityThread.java:5696) at java.lang.reflect.Method.invoke(Native Method) at java.lang.reflect.Method.invoke(Method.java:372) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1028) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:823) But my callstack (conceptually) is much longer, eg I called a setup method, it called another method, and another, and then the final method which hit the error. But my stacktrace is missing the earlier steps. |
Here's me trying to wrap exceptions at each step, seems like I get long stack traces
|
By thread switching I mean when you jump between different executors: task.continueWithTask((t) -> {
// ...
return t.continueWithTask((t) -> {
// ...
}, Task.UI_EXECUTOR);
}, Task.BACKGROUND_EXECUTOR); The code looks inline (ish), but since we're executing on different executors, each continuation will have it's own call stack. You're not doing anything wrong, it's just a nuance of the VM.
That's going to happen, but you could trim it if you want. I believe #11 has some of that logic. |
Thanks, that helps, I will look at using the same executor more consistently! I am often calling Parse functions, like saveInBackground etc. Should I use the network executor in my code so that if an exception happens saving with Parse then I get a better stack trace? (Assuming that the network executor is what Parse is using here) |
Thread switching isn't bad, it just doesn't give informative stack traces. As far as I know, starting off on the same executor doesn't guarantee nested or following continuations with the same executor will be inline on the current thread. In addition, there might be a different executor defined for a continuation somewhere down the chain that will jump threads. |
Hi, do you have any suggestions on how to manage exceptions? I end up getting very short stacktraces that start in Bolts code, and I lose all my context.
What i've started doing is adding ContinueWith calls that look for exceptions, and wrap them.
The text was updated successfully, but these errors were encountered: