-
-
Notifications
You must be signed in to change notification settings - Fork 168
docs: Document integrations and the Hub better #291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,17 @@ | ||
//! Adds support for capturing Sentry errors from `anyhow::Error`. | ||
//! Adds support for capturing Sentry errors from [`anyhow::Error`]. | ||
//! | ||
//! This integration adds a new event *source*, which allows you to create events directly | ||
//! from an [`anyhow::Error`] struct. As it is only an event source it only needs to be | ||
//! enabled using the `anyhow` cargo feature, it does not need to be enabled in the call to | ||
//! [`sentry::init`](../../fn.init.html). | ||
//! | ||
//! This integration does not need to be installed, instead it provides an extra function to | ||
//! capture [`anyhow::Error`], optionally exposing it as a method on the | ||
//! [`sentry::Hub`](../../struct.Hub.html) using the [`AnyhowHubExt`] trait. | ||
//! | ||
//! Like a plain [`std::error::Error`] being captured, [`anyhow::Error`] is captured with a | ||
//! chain of all error sources, if present. See | ||
//! [`sentry::capture_error`](../../fn.capture_error.html) for details of this. | ||
//! | ||
//! # Example | ||
//! | ||
|
@@ -13,6 +26,8 @@ | |
//! capture_anyhow(&err); | ||
//! } | ||
//! ``` | ||
//! | ||
//! [`anyhow::Error`]: https://docs.rs/anyhow/*/anyhow/struct.Error.html | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think intra-doc-links should handle this? Which reminds me, the relative links from above relative links will also fail when this is converted to the README via cargo-readme :-( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand what happened here. When trying to use the plain intra-doc links If you can get it to work with the intra-doc link then let me know what I did wrong! |
||
#![doc(html_favicon_url = "https://sentry-brand.storage.googleapis.com/favicon.ico")] | ||
#![doc(html_logo_url = "https://sentry-brand.storage.googleapis.com/sentry-glyph-black.png")] | ||
|
@@ -22,16 +37,27 @@ | |
use sentry_core::types::Uuid; | ||
use sentry_core::Hub; | ||
|
||
/// Captures an `anyhow::Error`. | ||
/// Captures an [`anyhow::Error`]. | ||
/// | ||
/// This will capture an anyhow error as a sentry event if a | ||
/// [`sentry::Client`](../../struct.Client.html) is initialised, otherwise it will be a | ||
/// no-op. The event is dispatched to the thread-local hub, with semantics as described in | ||
/// [`Hub::current`]. | ||
/// | ||
/// See [module level documentation](index.html) for more information. | ||
/// | ||
/// [`anyhow::Error`]: https://docs.rs/anyhow/*/anyhow/struct.Error.html | ||
pub fn capture_anyhow(e: &anyhow::Error) -> Uuid { | ||
Hub::with_active(|hub| hub.capture_anyhow(e)) | ||
} | ||
|
||
/// Hub extension methods for working with `anyhow`. | ||
/// Hub extension methods for working with [`anyhow`]. | ||
/// | ||
/// [`anyhow`]: https://docs.rs/anyhow | ||
pub trait AnyhowHubExt { | ||
/// Captures an [`anyhow::Error`] on a specific hub. | ||
/// | ||
/// [`anyhow::Error`]: https://docs.rs/anyhow/*/anyhow/struct.Error.html | ||
fn capture_anyhow(&self, e: &anyhow::Error) -> Uuid; | ||
} | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -64,28 +64,29 @@ impl HubImpl { | |
/// The central object that can manages scopes and clients. | ||
/// | ||
/// This can be used to capture events and manage the scope. This object is | ||
/// internally synchronized so it can be used from multiple threads if needed. | ||
/// [`Send`][std::marker::Send] and [`Sync`][std::marker::Sync] so it can be used from | ||
/// multiple threads if needed. | ||
/// | ||
/// Each thread has its own thread-local (`Hub::current()`) hub, which is | ||
/// automatically derived from the main hub (`Hub::main()`). | ||
/// Each thread has its own thread-local ( see [`Hub::current`]) hub, which is | ||
/// automatically derived from the main hub ([`Hub::main`]). | ||
/// | ||
/// In most situations developers do not need to interface with the hub directly. Instead | ||
/// toplevel convenience functions are expose that will automatically dispatch | ||
/// to the thread-local (`Hub::current()`) hub. In some situations this might not be | ||
/// to the thread-local ([`Hub::current`]) hub. In some situations this might not be | ||
/// possible in which case it might become necessary to manually work with the | ||
/// hub. This is for instance the case when working with async code. | ||
/// | ||
/// Hubs that are wrapped in `Arc`s can be bound to the current thread with | ||
/// Hubs that are wrapped in [`Arc`]s can be bound to the current thread with | ||
/// the `run` static method. | ||
/// | ||
/// Most common operations: | ||
/// | ||
/// * `Hub::new`: creates a brand new hub | ||
/// * `Hub::current`: returns the thread local hub | ||
/// * `Hub::with`: invoke a callback with the thread local hub | ||
/// * `Hub::with_active`: like `Hub::with` but does not invoke the callback if | ||
/// * [`Hub::new`]: creates a brand new hub | ||
/// * [`Hub::current`]: returns the thread local hub | ||
/// * [`Hub::with`]: invoke a callback with the thread local hub | ||
/// * [`Hub::with_active`]: like `Hub::with` but does not invoke the callback if | ||
/// the client is not in a supported state or not bound | ||
/// * `Hub::new_from_top`: creates a new hub with just the top scope of another hub. | ||
/// * [`Hub::new_from_top`]: creates a new hub with just the top scope of another hub. | ||
#[derive(Debug)] | ||
pub struct Hub { | ||
#[cfg(feature = "client")] | ||
|
@@ -115,31 +116,36 @@ impl Hub { | |
}) | ||
} | ||
|
||
/// Returns the current hub. | ||
/// Returns the current, thread-local hub. | ||
/// | ||
/// By default each thread gets a different thread local hub. If an | ||
/// atomically reference counted hub is available it can override this | ||
/// one here by calling `Hub::run` with a closure. | ||
/// Invoking this will return the current thread-local hub. The first | ||
/// time it is called on a thread, a new thread-local hub will be | ||
/// created based on the topmost scope of the hub on the main thread as | ||
/// returned by [`Hub::main`]. If the main thread did not yet have a | ||
/// hub it will be created when invoking this function. | ||
/// | ||
/// To have control over which hub is installed as the current | ||
/// thread-local hub, use [`Hub::run`]. | ||
/// | ||
/// This method is unavailable if the client implementation is disabled. | ||
/// When using the minimal API set use `Hub::with_active` instead. | ||
/// When using the minimal API set use [`Hub::with_active`] instead. | ||
#[cfg(feature = "client")] | ||
pub fn current() -> Arc<Hub> { | ||
Hub::with(Arc::clone) | ||
} | ||
|
||
/// Returns the main thread's hub. | ||
/// | ||
/// This is similar to `current` but instead of picking the current | ||
/// thread's hub it returns the main thread's hub instead. | ||
/// This is similar to [`Hub::current`] but instead of picking the | ||
/// current thread's hub it returns the main thread's hub instead. | ||
#[cfg(feature = "client")] | ||
pub fn main() -> Arc<Hub> { | ||
PROCESS_HUB.0.clone() | ||
} | ||
|
||
/// Invokes the callback with the default hub. | ||
/// | ||
/// This is a slightly more efficient version than `Hub::current()` and | ||
/// This is a slightly more efficient version than [`Hub::current`] and | ||
/// also unavailable in minimal mode. | ||
#[cfg(feature = "client")] | ||
pub fn with<F, R>(f: F) -> R | ||
|
@@ -149,7 +155,7 @@ impl Hub { | |
if USE_PROCESS_HUB.with(Cell::get) { | ||
f(&PROCESS_HUB.0) | ||
} else { | ||
// not on safety: this is safe because even though we change the Arc | ||
// note on safety: this is safe because even though we change the Arc | ||
// by temorary binding we guarantee that the original Arc stays alive. | ||
// For more information see: run | ||
THREAD_HUB.with(|stack| unsafe { | ||
|
@@ -159,7 +165,7 @@ impl Hub { | |
} | ||
} | ||
|
||
/// Like `Hub::with` but only calls the function if a client is bound. | ||
/// Like [`Hub::with`] but only calls the function if a client is bound. | ||
/// | ||
/// This is useful for integrations that want to do efficiently nothing if there is no | ||
/// client bound. Additionally this internally ensures that the client can be safely | ||
|
@@ -181,6 +187,13 @@ impl Hub { | |
} | ||
|
||
/// Binds a hub to the current thread for the duration of the call. | ||
/// | ||
/// During the execution of `f` the given hub will be installed as the | ||
/// thread-local hub. So any call to [`Hub::current`] during this time | ||
/// will return the provided hub. | ||
/// | ||
/// Once the function is finished executing, including after it | ||
/// paniced, the original hub is re-installed if one was present. | ||
#[cfg(feature = "client")] | ||
pub fn run<F: FnOnce() -> R, R>(hub: Arc<Hub>, f: F) -> R { | ||
let mut restore_process_hub = false; | ||
|
@@ -331,11 +344,11 @@ impl Hub { | |
|
||
/// End the current Release Health Session. | ||
/// | ||
/// See the global [`end_session`](crate::end_session_with) | ||
/// for more documentation. | ||
/// See the global [`sentry::end_session`](crate::end_session) for more documentation. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 thanks for fixing this ;-) |
||
pub fn end_session(&self) { | ||
self.end_session_with_status(SessionStatus::Exited) | ||
} | ||
|
||
/// End the current Release Health Session with the given [`SessionStatus`]. | ||
/// | ||
/// See the global [`end_session_with_status`](crate::end_session_with_status) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess these links are made in a way that they work when you are building
sentry
docs, and you expose this viaintegrations::anyhow
. However you should still be able to build the docs for this individually. Maybe intra-doc-links will just work when you havesentry
as a (circular) dev-dependency?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ugh, this was the only solution I could get this to work reasonably. I didn't think of it being standalone. I guess that's how it ends up on docs.rs though?
I tried adding the circular dependency under the "doc" feature but cargo was not having any of that. Do you think as a dev dependency would have more chance of working?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, sentry was already a circular dev dependency. so that doesn't work. So it's basically between this option which break the doc.rs build for the standalone crate, or point it to
https://docs.rs/sentry/*/sentry/fn.init.html
I think. Maybe the latter is the least evil :(