---
title: "Filtering"
description: "Learn more about how to configure your SDK to filter events reported to Sentry."
url: https://docs.sentry.io/platforms/dotnet/guides/entityframework/configuration/filtering/
---

# Filtering | Sentry for Entity Framework

When you add Sentry to your app, you get a lot of valuable information about errors and performance. And lots of information is good -- as long as it's the right information, at a reasonable volume.

The SDK has several configuration options to help you filter out events.

We also offer [Inbound Filters](https://docs.sentry.io/concepts/data-management/filtering.md) to filter events in sentry.io. We recommend filtering at the client level though, because it removes the overhead of sending events you don't actually want. Learn more about the [fields available in an event](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/).

## [Filtering Error Events](https://docs.sentry.io/platforms/dotnet/guides/entityframework/configuration/filtering.md#filtering-error-events)

To prevent certain errors from being reported to Sentry, use the `BeforeSend` or `AddExceptionFilter` configuration options, which allows you to evaluate whether to send an error or now. Alternatively, you can also control the behaviour by enabling, or disabling integrations.

### [Using `BeforeSend`](https://docs.sentry.io/platforms/dotnet/guides/entityframework/configuration/filtering.md#using-before-send)

The SDK supports the `BeforeSend` callback method. Because it's called immediately before the event is sent to the server, this is your last chance to decide not to send data or to edit it. `BeforeSend` receives the event object as a parameter, which you can use to either modify the event's data or drop it completely by returning `null`, based on custom logic and the data available on the event.

A `Func<SentryEvent, Hint, SentryEvent?>` can be used to mutate, discard (return null), or return a completely new event.

```csharp
// Add this to the SDK initialization callback
options.SetBeforeSend((sentryEvent, hint) =>
{
    if (sentryEvent.Exception != null
      && sentryEvent.Exception.Message.Contains("Noisy Exception"))
    {
        return null; // Don't send this event to Sentry
    }

    sentryEvent.ServerName = null; // Never send Server Name to Sentry
    return sentryEvent;
});
```

*Other available variations of the above snippet: fsharp*

Note also that breadcrumbs can be filtered, as discussed in [our Breadcrumbs documentation](https://docs.sentry.io/product/issues/issue-details/breadcrumbs.md).

#### [Filtering by Unhandled or Terminal Exceptions](https://docs.sentry.io/platforms/dotnet/guides/entityframework/configuration/filtering.md#filtering-by-unhandled-or-terminal-exceptions)

When filtering events in `BeforeSend`, you may want to treat unhandled exceptions differently from handled ones. For example, you might drop noisy exceptions (like network timeouts) if these were handled, but capture them if they crashed your app.

The SDK provides two extension methods on `SentryEvent` to enable this:

* `IsFromUnhandledException()` returns `true` when the event came from an exception that wasn't caught by your application code, but was instead captured through an unhandled exception hook (such as `AppDomain.UnhandledException`, ASP.NET Core middleware, or another integration).
* `IsFromTerminalException()` returns `true` only when the unhandled exception caused the application to crash. Some integrations capture unhandled exceptions that don't terminate the process (for example, unobserved task exceptions) and mark them as non-terminal.

```csharp
options.SetBeforeSend((sentryEvent, hint) =>
{
    // Always send unhandled exceptions, even if they'd be filtered below
    if (sentryEvent.IsFromUnhandledException())
    {
        return sentryEvent;
    }

    // Drop noisy handled exceptions
    if (sentryEvent.Exception is HttpRequestException)
    {
        return null; // Don't send this event to Sentry
    }

    return sentryEvent;
});
```

*Other available variations of the above snippet: fsharp*

### [Using `AddExceptionFilter` and `AddExceptionFilterForType`](https://docs.sentry.io/platforms/dotnet/guides/entityframework/configuration/filtering.md#using-add-exception-filterand-add-exception-filter-for-type)

The SDK also allows you to provide your own, custom exception filters. These have to inherit from `IExceptionFilter`

```csharp
public class MyExceptionFilter : IExceptionFilter
{
    public bool Filter(Exception ex)
    {
        // TODO: Add your filtering logic
    }
}
```

and can then be provided to the options during initialization.

```csharp
options.AddExceptionFilter(new MyExceptionFilter());
```

Exception types provided via `AddExceptionFilterForType` automatically get filtered and prevented from being set to Sentry.

```csharp
options.AddExceptionFilterForType<MyCustomException>();
```

## [Filtering Transaction Events](https://docs.sentry.io/platforms/dotnet/guides/entityframework/configuration/filtering.md#filtering-transaction-events)

To prevent certain transactions from being reported to Sentry, use the `TracesSampler` or `BeforeSendTransaction` configuration option, which allows you to provide a function to evaluate the current transaction and drop it if it's not one you want.

### [Using `TracesSampler`](https://docs.sentry.io/platforms/dotnet/guides/entityframework/configuration/filtering.md#using-traces-sampler)

**Note:** The `TracesSampler` and `TracesSampleRate` config options are mutually exclusive. If you define a `TracesSampler` to filter out certain transactions, you must also handle the case of non-filtered transactions by returning the rate at which you'd like them sampled.

In its simplest form, used just for filtering the transaction, it looks like this:

```csharp
// Add this to the SDK initialization callback
options.TracesSampler = samplingContext =>
{
    if (/* make a decision based on `samplingContext` */) {
      // Drop this transaction, by setting its sample rate to 0%
      return 0;
    } else if (/* ... */) {
      // Override sample rate for other cases (replaces `options.TracesSampleRate`)
      return 0.1;
    }

    // Can return `null` to fallback to the rate configured by `options.TracesSampleRate`
    return null;
};
```

It also allows you to sample different transactions at different rates.

If the transaction currently being processed has a parent transaction (from an upstream service calling this service), the parent (upstream) sampling decision will always be included in the sampling context data, so that your `TracesSampler` can choose whether and when to inherit that decision. In most cases, inheritance is the right choice, to avoid breaking distributed traces. A broken trace will not include all your services. See [Inheriting the parent sampling decision](https://docs.sentry.io/platforms/dotnet/guides/entityframework/configuration/sampling.md#inheritance) to learn more.

Learn more about [configuring the sample rate](https://docs.sentry.io/platforms/dotnet/guides/entityframework/configuration/sampling.md).

### [Using `BeforeSendTransaction`](https://docs.sentry.io/platforms/dotnet/guides/entityframework/configuration/filtering.md#using-before-send-transaction)

A `Func<SentryTransaction, Hint, SentryTransaction?>` can be used to update the transaction or drop it by returning `null` before it gets sent to Sentry. For example:

```csharp
// Add this to the SDK initialization callback
options.SetBeforeSendTransaction((sentryTransaction, hint) =>
{
    // Modify the transaction
    if (sentryTransaction.Operation.Equals("http.server"))
    {
        return null; // Drop the transaction by returning null
    }

    return sentryTransaction;
});
```