Add Roslyn analyzer to detect improper catching of DotvvmInterruptRequestExecutionException

[Copilot]

Users wrapping ReturnFile* or Redirect* calls in try-catch blocks inadvertently swallow DotvvmInterruptRequestExecutionException, breaking request flow control.

Changes

• New analyzer (DotVVM06): Detects when ReturnFile* or RedirectTo* methods on IDotvvmRequestContext are called within try-catch blocks that catch DotvvmInterruptRequestExecutionException (or base types like Exception) without rethrowing
• Flexible rethrow detection: Allows throw; anywhere in catch block, including inside if statements or other nested operations
• When clause support: Recognizes when clauses that exclude the interrupt exception (e.g., when (ex is not DotvvmInterruptRequestExecutionException))
• Nested try block validation: Validates all enclosing try blocks to ensure the exception properly propagates through nested try-catch structures
• Bare catch block handling: Bare catch { } blocks (without exception type) are always flagged as problematic since we cannot reliably detect rethrows within them. Users should use explicit exception types instead.
• Resource strings: Added localized diagnostic messages
• Tests: 20 test cases covering various redirect/return file methods, nested try-catch, when clauses, bare catch blocks, and edge cases

Example

The analyzer flags these patterns:

// Catching base exception without rethrow
try
{
    await context.ReturnFileAsync(bytes, "file.csv", "application/octet-stream");
}
catch (Exception ex)  // DotVVM06: DotvvmInterruptRequestExecutionException must be rethrown
{
    // Handle exceptions
}

// Bare catch block (always flagged)
try
{
    await context.ReturnFileAsync(bytes, "file.csv", "application/octet-stream");
}
catch  // DotVVM06: DotvvmInterruptRequestExecutionException must be rethrown
{
    throw;  // Even with rethrow, bare catch is flagged
}

And accepts these patterns:

// Rethrow in dedicated catch block
try
{
    await context.ReturnFileAsync(bytes, "file.csv", "application/octet-stream");
}
catch (DotvvmInterruptRequestExecutionException)
{
    throw;
}
catch (Exception ex)
{
    // Handle other exceptions
}

// Rethrow inside if statement
try
{
    await context.ReturnFileAsync(bytes, "file.csv", "application/octet-stream");
}
catch (DotvvmInterruptRequestExecutionException ex)
{
    if (someCondition)
    {
        throw;
    }
}

// Exclude using when clause
try
{
    await context.ReturnFileAsync(bytes, "file.csv", "application/octet-stream");
}
catch (Exception ex) when (ex is not DotvvmInterruptRequestExecutionException)
{
    // Handle other exceptions only
}

Warning

<issue_title>Roslyn analyzer to detect catching DotvvmInterruptRequestExecutionException</issue_title>
<issue_description>A couple of users were dealing with this unintuitive behavior - when they perform a redirect or returning a file, they wrap it in a try/catch block, and catch all exceptions. However, DotVVM throws DotvvmInterruptRequestExecutionException which needs to be rethrown.

public async Task OnDownloadFile()
{
  try
  {
     ...
     await Context.ReturnFileAsync(bytes, "file.csv", "application/octet-stream");
  }
  catch (System.Exception ex)
  {
    ...
  }
}

We already have Roslyn analyzers in the project. We should detect this pattern when ReturnFile* or Redirect* is called on IDotvvmRequestContext, and if it is inside try/catch block, ensure there is a special case for DotvvmInterruptRequestExecutionException where the exception is rethrown as such:

  catch (DotvvmInterruptRequestExecutionException) 
  {
    throw;
  }
```</issue_description>

<agent_instructions>There is already a project with analyzers - implement it there. 
There is also a project with tests for the analyzers - make sure that the functionality is covered by tests.</agent_instructions>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes Roslyn analyzer to detect catching DotvvmInterruptRequestExecutionException #1964

<issue_title>Roslyn analyzer to detect catching DotvvmInterruptRequestExecutionException</issue_title>

<issue_description>A couple of users were dealing with this unintuitive behavior - when they perform a redirect or returning a file, they wrap it in a try/catch block, and catch all exceptions. However, DotVVM throws DotvvmInterruptRequestExecutionException which needs to be rethrown.

public async Task OnDownloadFile()
{
  try
  {
     ...
     await Context.ReturnFileAsync(bytes, "file.csv", "application/octet-stream");
  }
  catch (System.Exception ex)
  {
    ...
  }
}

We already have Roslyn analyzers in the project. We should detect this pattern when ReturnFile* or Redirect* is called on IDotvvmRequestContext, and if it is inside try/catch block, ensure there is a special case for DotvvmInterruptRequestExecutionException where the exception is rethrown as such:

  catch (DotvvmInterruptRequestExecutionException) 
  {
    throw;
  }
```</issue_description>

<agent_instructions>There is already a project with analyzers - implement it there. 
There is also a project with tests for the analyzers - make sure that the functionality is covered by tests.</agent_instructions>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes Roslyn analyzer to detect catching DotvvmInterruptRequestExecutionException #1964

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Roslyn analyzer to detect catching DotvvmInterruptRequestExecutionException</issue_title>
<issue_description>A couple of users were dealing with this unintuitive behavior - when they perform a redirect or returning a file, they wrap it in a try/catch block, and catch all exceptions. However, DotVVM throws DotvvmInterruptRequestExecutionException which needs to be rethrown.

public async Task OnDownloadFile()
{
  try
  {
     ...
     await Context.ReturnFileAsync(bytes, "file.csv", "application/octet-stream");
  }
  catch (System.Exception ex)
  {
    ...
  }
}

We already have Roslyn analyzers in the project. We should detect this pattern when ReturnFile* or Redirect* is called on IDotvvmRequestContext, and if it is inside try/catch block, ensure there is a special case for DotvvmInterruptRequestExecutionException where the exception is rethrown as such:

  catch (DotvvmInterruptRequestExecutionException) 
  {
    throw;
  }
```</issue_description>

<agent_instructions>There is already a project with analyzers - implement it there. 
There is also a project with tests for the analyzers - make sure that the functionality is covered by tests.</agent_instructions>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes Roslyn analyzer to detect catching DotvvmInterruptRequestExecutionException #1964

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[tomasherceg]

@copilot Please look at my review comments and make the requested changes.

[tomasherceg]

@copilot Does this mean that if there is just catch { ... }, we just ignore it and report that the exception is handled correctly? Can you verify this by adding a test for the catch clause without the specified exception type?

[Copilot]

You're correct - the original code was skipping bare catch { } blocks entirely. I've now fixed this by handling bare catch blocks conservatively: they always trigger the analyzer warning, regardless of whether they contain a throw; statement. This is because we cannot reliably detect rethrows in bare catch blocks through Roslyn's operation tree. Users should use catch (DotvvmInterruptRequestExecutionException) { throw; } instead for proper handling. Added tests for bare catch blocks with and without rethrows - both now correctly trigger warnings. Commit: 94f1b1a