dotnet / dotnet/roslyn

Proposal: Add a code style analyzer to detect swallowed exceptions

Open
#84,408 0 comments 0 reactions 0 assignees View on GitHub
Area-IDE Feature Request
Dominant language
C#
Stars
20.7k
Forks
4.3k
PR merge metrics
PR metrics pending

Description

**Brief description:**

Exceptions that are caught but silently ignored can obscure application failures, complicate debugging, and leave an application in an inconsistent state. While there are legitimate scenarios where ignoring an exception is appropriate (for example, best-effort cleanup), such intent should be explicit rather than implicit.

Propose a code style analyzer that identifies `catch` blocks which swallow exceptions without any observable handling. The analyzer should encourage developers to either:

- Rethrow the exception.
- Wrap and rethrow the exception.
- Perform meaningful recovery or cleanup.
- Explicitly document that the exception is intentionally ignored.

The goal of this analyzer is to improve code readability, aid maintenance, and make accidental exception swallowing distinguishable from intentional exception suppression.

**Languages applicable:**

C#

**Code example that the analyzer should report:**

Empty `catch` block:

```csharp
try
{
SaveDocument(document);
}
catch (IOException)
{
}
```

Ignoring the caught exception:

```csharp
try
{
ProcessConfiguration();
}
catch (ConfigurationException ex)
{
}
```

Catch-all with no handling:

```csharp
try
{
Initialize();
}
catch
{
}
```

Exception caught only to continue execution:

```csharp
foreach (var file in files)
{
try
{
Process(file);
}
catch (Exception)
{
}
}
```

Examples that should **not** report:

Rethrowing the exception:

```csharp
try
{
SaveDocument(document);
}
catch
{
throw;
}
```

Wrapping the exception:

```csharp
try
{
LoadConfiguration(path);
}
catch (IOException ex)
{
throw new ConfigurationException(
$"Failed to load configuration '{path}'.",
ex);
}
```

Performing meaningful recovery:

```csharp
try
{
LoadConfiguration(path);
}
catch (FileNotFoundException)
{
configuration = Configuration.CreateDefault();
}
```

Intentional suppression with documented rationale:

```csharp
try
{
File.Delete(tempFile);
}
catch (IOException)
{
// Intentionally ignored. Failure to delete temporary files
// should not prevent application shutdown.
}
```

**Additional information:**

Silently swallowing exceptions is a common source of hidden defects because it suppresses information that would otherwise help diagnose failures. Empty or effectively empty `catch` blocks can make production issues difficult to detect and debug.

The analyzer should report `catch` blocks that do not perform any observable action, such as:

- Empty `catch` blocks.
- `catch` blocks that contain only comments or whitespace.
- `catch` blocks where the caught exception is ignored and no meaningful action is taken.

The analyzer should not report cases where the exception is:

- Rethrown.
- Wrapped and rethrown.
- Used to perform meaningful recovery or cleanup.
- Intentionally ignored with an explanatory comment describing why suppression is appropriate.

The purpose of this analyzer is not to require a particular logging framework or exception-handling strategy, but to encourage explicit intent whenever an exception is caught.

**Documentation requirements:**

When this analyzer is implemented, it must be documented by following the steps at [Documentation for IDE CodeStyle analyzers](https://github.com/dotnet/roslyn/blob/main/docs/contributing/Documentation%20for%20IDE%20CodeStyle%20analyzers.md).

Contributor guide

Open the contributing guide

Research direction

Start by reading GuidelinesForNewRules.md and Documentation for IDE CodeStyle analyzers, both linked in the issue. Define the analyzer behavior from the listed reporting and non-reporting examples, including documented intentional suppression. Done means the proposed cases are distinguished as specified and the analyzer documentation follows the required steps.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.