Automatic Error Capture

Learn more about how the SDK automatically captures errors and sends them to Sentry.

The Sentry SDK for Unity provides both automatic and manual error capturing capabilities. This page focuses on the automatic error capture through Unity's logging system integrations. For information on manually capturing errors and messages, see the Usage documentation.

The Unity SDK relies on two integrations to automatically capture errors: UnityLogHandlerIntegration and UnityApplicationLoggingIntegration. While they sound similar, they serve different purposes.

The SDK uses the UnityLogHandlerIntegration to hook into Unity's logging system. From there it receives all log messages that are logged via the Debug.Log, Debug.LogWarning, and Debug.LogError methods and those log messages are added as breadcrumbs to future events. By default, the SDK will also automatically capture messages logged via Debug.LogError as error events and send them to Sentry. This behaviour can be disabled by unchecking the automatic capture of Debug.LogError on the Enrichment tab, or programmatically, by setting the CaptureLogErrorEvents option to false in the configure callback.

If configured, Unity will include the stack traces with the log messages as raw strings. The SDK is able to parse and display this stack trace in the issues details.

If you're using Unity 6 or newer, you have the option to to enable the source code line numbers in the player settings. These line numbers are then part of the stringified stack trace and will be parsed by the SDK. Unfortunately, since there is no native exception at the time of logging, the SDK is not be able to provide line numbers otherwise.

The SDK uses the UnityApplicationLoggingIntegration to add its own log handler right before Unity's logging system. It then passes the logs back to Unity. This allows the SDK to capture errors through the Application.logMessageReceived method. All handled exceptions - such as those captured via Log.LogException calls - and unhandled exceptions end up on that call and are captured by the SDK. These messages contain the actual exception object. This allows the SDK to call into the IL2CPP backend and connect this managed exception to the native exception, allowing for server side symbolication. You can read more about the IL2CPP error integration works here.

Was this helpful?
Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").