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.

Copied
import Sentry

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

Capturing Uncaught Exceptions in macOS

By default, macOS applications do not crash whenever an uncaught exception occurs. 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

Customizing Error Descriptions

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

Sentry will display the error code in the error description field by default. For custom error types, you may want to provide a custom description to make it easier to identify the error in the Issues page. For NSError values, this can be done 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.

This can be particularly useful for Swift enum error types that conform to Error, where the error code can be hard to match with an enum case. To customize the description for Swift Error types, you should conform to the CustomNSError protocol and return a user info dictionary:

Copied
enum MyCustomError: Error {
    case indexOutOfBounds
    case enumeratingWhileMutating
}

extension MyCustomError: CustomNSError {
    var errorUserInfo: [String : Any] {
        func getDebugDescription() -> String {
            switch self {
            case .indexOutOfBounds:
                return  "indexOutOfBounds"
            case .enumeratingWhileMutating:
                return "enumeratingWhileMutating"
            }
        }

        return [NSDebugDescriptionErrorKey: getDebugDescription()]
    }
}

Capturing Messages

Another common operation is to capture a bare message. A message is textual information that should be sent to Sentry. Typically messages are not emitted, but they can be useful for some teams.

Copied
import Sentry

SentrySDK.capture(message: "My first test message")
Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").