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.

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.

In PowerShell you can capture any [ErrorRecord] object that you caught:

Copied
try
{
    AFunctionThatMightFail
}
catch
{
    $_ | Out-Sentry
}

Or you can install a trap in a block to log errors that occur within that block. Be sure to understand how trap works especially in regards to scope and how the execution continues/breaks when trap is used.

Copied
AFunctionThatMightFail

# The trap will get called even if it is declared after the code that throws.
# It's because traps are processed by PowerShell before the script is executed.
trap 
{
    $_ | Out-Sentry
}

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.

Copied
"Something went wrong" | Out-Sentry
Help improve this content
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").