Usage
Use the SDK to manually capture errors and other events.
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.
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)
}
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 |
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)
}
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!) or suggesting an update ("yeah, this would be better").