# Usage | Sentry for macOS

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.

Key terms:

* An *event* is one instance of sending data to Sentry. Generally, this data is an error or exception.
* An *issue* is a grouping of similar events.
* The reporting of an event is called *capturing*. When an event is captured, it’s sent to Sentry.

## [Capturing Messages](https://docs.sentry.io/platforms/apple/guides/macos/usage.md#capturing-messages)

The simplest operation is to capture a bare message: textual information that should be sent to Sentry. Typically, our SDKs won'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.

```swift
import Sentry

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

## [Capturing Errors](https://docs.sentry.io/platforms/apple/guides/macos/usage.md#capturing-errors)

The most common usage of the Apple SDKs is to capture errors. In general, if you have something that looks like an exception, it can be captured, though this varies by platform. For some SDKs, you can also omit the argument to `captureException` and Sentry will attempt to capture the current exception. This 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 in our [Breadcrumbs documentation](https://docs.sentry.io/platforms/apple/guides/macos/enriching-events/breadcrumbs.md).

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.

```swift
import Sentry

enum MyCustomError: Error {
    case myFirstIssue
}

func thisFunctionThrows() throws {
    throw MyCustomError.myFirstIssue
} 

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

### [Swift Errors](https://docs.sentry.io/platforms/apple/guides/macos/usage.md#swift-errors)

For Swift Errors conforming to the [Error Protocol](https://developer.apple.com/documentation/swift/error) 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](https://github.com/getsentry/sentry-cocoa/blob/main/CHANGELOG.md#870) the SDK only sends the domain and error code.

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

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

For the Swift error above Sentry displays:

| sentry-cocoa SDK | Title        | Description                           |
| ---------------- | ------------ | ------------------------------------- |
| Since 8.7.0      | `LoginError` | `wrongUser(id: "12345678") (Code: 1)` |
| Before 8.7.0     | `LoginError` | `Code: 1`                             |

### [Customizing Error Descriptions](https://docs.sentry.io/platforms/apple/guides/macos/usage.md#customizing-error-descriptions)

This feature is available on [sentry-cocoa 7.25.0](https://github.com/getsentry/sentry-cocoa/blob/main/CHANGELOG.md#7250) 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`.

`NSLocalizedDescription` (or `NSLocalizedDescriptionKey`) will not be used for the issue title in Sentry. This is intentional to prevent duplicate issues, as localized descriptions can vary and lead to incorrect grouping. Only `NSDebugDescriptionErrorKey` is used for customizing the issue title.

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`](https://developer.apple.com/documentation/foundation/customnserror) protocol and return a user info dictionary:

```swift
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.

```swift

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](https://docs.sentry.io/platforms/apple/guides/macos/usage.md#capturing-uncaught-exceptions)

The SDK can't install the uncaught exception handler if a debugger is attached. To test these locally, ensure you've unchecked the "Debug executable" option in your app's Xcode scheme's Run action.

By default, macOS applications don't crash whenever an uncaught exception occurs. As the Cocoa Frameworks are generally not [exception-safe on macOS](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Exceptions/Articles/ExceptionsAndCocoaFrameworks.html), 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](https://github.com/getsentry/sentry-cocoa/blob/main/CHANGELOG.md#8400). 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](https://docs.sentry.io/platforms/apple/guides/macos/usage.md#sentrycrashexceptionapplication)

Don't use this option together with the `enableUncaughtNSExceptionReporting` option. Enabling both features can lead to duplicated reports.

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](https://docs.sentry.io/platforms/apple/guides/macos/usage.md#uncaught-nsexception-reporting-option)

Don't use this option together with the `SentryCrashExceptionApplication`. Enabling both features can lead to duplicated reports.

As of version [8.40.0](https://github.com/getsentry/sentry-cocoa/blob/main/CHANGELOG.md#8400), 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`](https://developer.apple.com/documentation/swiftui/nsapplicationdelegateadaptor), for which you can't easily use the `SentryCrashExceptionApplication` class.

```swift
import Sentry

SentrySDK.start { options in
    options.dsn = "___PUBLIC_DSN___"
    options.enableUncaughtNSExceptionReporting = true
}
```