Usage
Capturing Errors
If you use the LoggerBackend and set up the Plug/Phoenix integrations, all errors will bubble up to Sentry.
Otherwise, we provide a simple way to capture exceptions manually:
Copied
try do
ThisWillError.really()
rescue
my_exception ->
Sentry.capture_exception(my_exception, [stacktrace: __STACKTRACE__, extra: %{extra: information}])
end
Optional Attributes
With calls to capture_exception
additional data can be supplied as a keyword list:
CopiedSentry.capture_exception(exception, opts)
extra
- Additional context for this event. Must be a mapping. Children can be any native JSON type.
Copied
extra: %{key: "value"}
level
- The level of the event. Defaults to
error
.
Copied
level: "warning"
Sentry is aware of the following levels:
- debug (the least serious)
- info
- warning
- error
- fatal (the most serious)
fingerprint
- The fingerprintThe set of characteristics that define an event.for grouping this event.
tags
- Tags to index with this event. Must be a mapping of strings.
Copied
tags: %{"key" => "value"}
user
- The acting user.
Copied
user: %{
"id" => 42,
"email" => "email@email.com"
}
event_source
- The source of the event. Used by the
Sentry.EventFilter
behaviour
.
Breadcrumbs
Sentry supports capturing breadcrumbs – events that happened prior to an issue. We need to be careful because breadcrumbs are per-process. If a process dies it might lose its context.
Copied
Sentry.Context.add_breadcrumb(%{my: "crumb"})
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").
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").
Suggest an edit to this page | Contribute to Docs | Report a problem
🎉 Thank you for your feedback! 🙌