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.
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.
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:
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
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 should 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] {
func getDebugDescription() -> String {
switch self {
case .indexOutOfBounds:
return "indexOutOfBounds"
case .enumeratingWhileMutating:
return "enumeratingWhileMutating"
}
}
return [NSDebugDescriptionErrorKey: getDebugDescription()]
}
}
Capturing Uncaught Exceptions in macOS
By default, macOS applications do not crash whenever an uncaught exception occurs. To enable this with Sentry:
- Open the application's
Info.plist
file - Search for
Principal class
(the entry is expected to beNSApplication
) - Replace
NSApplication
withSentryCrashExceptionApplication
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.
import Sentry
SentrySDK.capture(message: "My first test message")
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").
- Package:
- cocoapods:sentry-cocoa
- Version:
- 8.13.0
- Repository:
- https://github.com/getsentry/sentry-cocoa