Is there any technical reason to write a catch block containing only a throw statement?

Question

Disclaimer: It is well known that catch (ex) { throw ex; } is bad practice. This question is not about that.

---

While digging through Microsoft reference sources, I noticed the following pattern in a lot of methods:

try {
    ...
} catch {
    throw;
}

No logging, no debugging code—just a plain simple catch { throw; }.

Since, obviously, the guys at Microsoft should be fairly proficient in the use of C#, what could be the point of doing that instead of just omitting the catch block (and the try statement) altogether? Is there a technical reason for coding like this, or is it purely a stylistic choice?

Note: I don't know if it is relevant, but all such instances I could find also contain a try-finally block nested inside the try clause of the try-catch block.

Answer 1

It affects when exception filters run.

Given

void f() {
  using (var x = AcquireResource()) {
    x.DoSomething();
    x.DoSomethingElse();
  }
}

versus

void f() {
  try {
    using (var x = AcquireResource()) {
      x.DoSomething();
      x.DoSomethingElse();
    }
  } catch {
    throw;
  }
}

with

void g() {
  try {
    f();
  } catch (Exception ex) when (h()) {
    // ...
  }
}

The first version of f would allow the filter h() to be called before x got disposed. The second version of f ensures that x is disposed before external code is run.

In the code you link to, SqlConnectionHolder is used a lot, and catch { throw; } blocks are all around the use of SqlConnectionHolder.

Answer 2

As C# Specification describes:

When an exception occurs, the system searches for the nearest catch clause that can handle the exception, as determined by the run-time type of the exception. First, the current method is searched for a lexically enclosing try statement, and the associated catch clauses of the try statement are considered in order. If that fails, the method that called the current method is searched for a lexically enclosing try statement that encloses the point of the call to the current method. This search continues until a catch clause is found that can handle the current exception, by naming an exception class that is of the same class, or a base class, of the run-time type of the exception being thrown. A catch clause that doesn't name an exception class can handle any exception.

Once a matching catch clause is found, the system prepares to transfer control to the first statement of the catch clause. Before execution of the catch clause begins, the system first executes, in order, any finally clauses that were associated with try statements more nested that than the one that caught the exception.

in case of exception runtime first looks for catch clause that can handle it, which involve executing any associated exception filters. Undiscriminating catch block interrupt that search and make all nested finally blocks to be executed immediately.

That can be useful when you want to prevent caller from executing arbitrary code (in form of exception filter) before finally block. For example, when finally block affect security context of current thread.

Also, if exception will not be caught by any catch clause, then it will lead to thread termination. And in that case C# Specification did not provide any guaranty, that any finally block will be executed at all.

If the search for matching catch clauses reaches the code that initially started the thread, then execution of the thread is terminated. The impact of such termination is implementation-defined.

Answer 3

The code you linked is actually a very good example.

In my eyes, one should only use try catch blocks when dealing with things outside of their control, like file systems, external things basically.

In the code you linked the try catch is around the database stuff.

What this means is that by using this way of coding, they make sure there are no leaks, no connections remain open.

If anything goes wrong, such as wrong connection string, missing tables, whatever, the code is going to continue to execute, it will gracefully close the connection as shown in the finally block and it will finally throw meaning it will allow the client of that code to get the proper exception, get the entire stack as well and let them decide what to do when that happens.

To be honest I quite like what they did there.