Usage

Sentry's SDK hooks into your runtime environment and automatically reports errors, uncaught exceptions, and unhandled rejections as well as other types of errors depending on the platform.

The most common form of capturing is to capture errors. What can be captured as an error varies by platform. In general, if you have something that looks like an exception, it can be captured. For some SDKs, you can also omit the argument to captureException and Sentry will attempt to capture the current exception. It is also useful for manual reporting of errors or messages to Sentry.

While capturing an event, you can also record the breadcrumbs that lead up to that event. Breadcrumbs are different from events: they will not create an event in Sentry, but will be buffered until the next event is sent. Learn more about breadcrumbs in our Breadcrumbs documentation.

Capturing Errors

You can capture errors with the captureError method. This method takes an Error object as a parameter. The Error object can be an NSError or a Swift.Error object.

import Sentry

do {
    try aMethodThatMightFail()
} catch {
    SentrySDK.capture(error: error)
}

Swift Errors

For Swift Errors conforming to the Error Protocol the SDK sends the domain, code and the description of the Swift error. For older versions of the SDK, prior to sentry-cocoa 8.7.0 the SDK only sends the domain and error code.

enum LoginError: Error {
    case wrongUser(id: String)
    case wrongPassword
}

SentrySDK.capture(error: LoginError.wrongUser("12345678"))

For the Swift error above Sentry displays:

Customizing Error Descriptions

This feature is available on sentry-cocoa 7.25.0 and above.

You may want to provide a custom description to make identifying the error in the Issues page easier. For NSError values, you can do this by adding a description to the userInfo dictionary with the key NSDebugDescriptionErrorKey.

Sentry will group errors based on the error domain and code, and by enum value for Swift enum types, so customizing error descriptions won’t impact grouping.

To customize the description for Swift Error types, you can conform to the CustomNSError protocol and return a user info dictionary:

enum MyCustomError: Error {
    case indexOutOfBounds
    case enumeratingWhileMutating
}

extension MyCustomError: CustomNSError {
    var errorUserInfo: [String : Any] {
        return [NSDebugDescriptionErrorKey: getDebugDescription()]
    }

    private func getDebugDescription() -> String {
        switch self {
        case .indexOutOfBounds:
            return "indexOutOfBounds"
        case .enumeratingWhileMutating:
            return "enumeratingWhileMutating"
        }
    }
}

If you have an existing Swift Error and want to change the domain, code, or description, you can cast the Swift Error to an NSError and create a new NSError object with your desired information.

import Sentry

do {
    try aMethodThatMightFail()
} catch {
    let nsError = error as NSError
    let myError = NSError(
        domain: "your domain",
        code: nsError.code, // Keep the error code
        userInfo: [NSDebugDescriptionErrorKey : "my custom description"]
    )
    SentrySDK.capture(error: myError)
}

Capturing Uncaught Exceptions

By default, macOS applications don't crash whenever an uncaught exception occurs. As the Cocoa Frameworks are generally not exception-safe on macOS, the application could end up in a corrupted state when an uncaught exception occurs. Therefore, we recommend changing your application configuration so it crashes on uncaught NSExceptions. To achieve this, you can use the SentryCrashExceptionApplication, or enable the option enableUncaughtNSExceptionReporting, available as of version 8.40.0. Both options set the NSApplicationCrashOnExceptions on the NSUserDefaults so your application crashes on uncaught NSExceptions and send the crash report to Sentry.

Once you have configured your application to crash whenever an uncaught exception occurs, the Apple SDK will capture those automatically. You don't need to manually call captureException.

SentryCrashExceptionApplication

To enable this with Sentry:

1. Open the application's Info.plist file
2. Search for Principal class (the entry is expected to be NSApplication)
3. Replace NSApplication with SentryCrashExceptionApplication

Uncaught NSException Reporting Option

As of version 8.40.0, you can enable uncaught NSException reporting by setting the enableUncaughtNSExceptionReporting option to true. This is especially useful for applications using the SwiftUI lifecycle in combination with the NSApplicationDelegateAdaptor, for which you can't easily use the SentryCrashExceptionApplication class.

import Sentry

SentrySDK.start { options in
    options.dsn = "https://examplePublicKey@o0.ingest.sentry.io/0"
    options.enableUncaughtNSExceptionReporting = true
}

Capturing Messages

Another common operation is to capture a bare message. A message is textual information that should be sent to Sentry. Typically, our SDKs don't automatically capture messages, but you can capture them manually.

Messages show up as issues on your issue stream, with the message as the issue name.

import Sentry

SentrySDK.capture(message: "My first test message")