# Improving Error Logging with Asynchronous Stack Traces

DevFeed: [Improving Error Logging with Asynchronous Stack Traces](<https://devfeed.tech/articles/better-error-logging-19213.md>)

Original publisher: [Read original article](<https://www.codenameone.com/blog/better-error-logging/>)

Author: Shai Almog

Published: 2019-04-15T00:00:00Z

Content type: tutorial

Language: en

Sources: [CodeName One](<https://devfeed.tech/sources/codename-one.md>)

Topics: [GUI](<https://devfeed.tech/topics/gui.md>), [debug](<https://devfeed.tech/topics/debug.md>), [Exception](<https://devfeed.tech/topics/exception.md>), [bug](<https://devfeed.tech/topics/bug.md>), [App](<https://devfeed.tech/topics/app.md>)

Tags: [app](<https://devfeed.tech/tags/app.md>), [bug](<https://devfeed.tech/tags/bug.md>), [code](<https://devfeed.tech/tags/code.md>), [crash](<https://devfeed.tech/tags/crash.md>), [debug](<https://devfeed.tech/tags/debug.md>), [gui](<https://devfeed.tech/tags/gui.md>), [logging](<https://devfeed.tech/tags/logging.md>)

## AI overview

This article explains how asynchronous calls can hide the original stack trace in production error reports. It describes enabling fake exceptions to preserve the original cause, while warning that the feature may impose a performance cost and is better suited to user configuration or debug builds.

## Source excerpt

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: