Architecture scenarioHard~12 min

Interview question

Where should exceptions be caught in a .NET application, and what is the difference between throw and throw ex when rethrowing?

Exception boundaries, rethrowing, and exception filters

Preserves failure context, catches only where recovery or translation is possible, and uses filters without hiding unrelated faults.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I catch an exception where I can do something specific: retry a transient operation, translate a dependency error into an application result, release or compensate work, or turn an unhandled request failure into a stable API response. If I only need the same exception to continue, I use throw; inside the catch block because it preserves the original stack trace. throw ex; throws from the current location and loses the original call path. I avoid broad catch blocks in every method because they duplicate logs and hide where recovery actually belongs.

Full answer below

Practice focus

Exception boundaries, recovery, translation, stack preservation, filters, logging ownership, cancellation, and stable error contracts.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Catching an exception is an ownership decision. The useful question is whether the current layer can recover, add meaningful context, or translate the failure into its own contract.
I catch an exception where I can do something specific: retry a transient operation, translate a dependency error into an application result, release or compensate work, or turn an unhandled request failure into a stable API response. If I only need the same exception to continue, I use throw; inside the catch block because it preserves the original stack trace. throw ex; throws from the current location and loses the original call path. I avoid broad catch blocks in every method because they duplicate logs and hide where recovery actually belongs.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, a repository may let a database timeout propagate with its full technical context, while an application boundary maps a known unique-key violation to a conflict result. Unexpected exceptions reach centralized middleware, which assigns a correlation ID, logs once, and returns a non-sensitive problem response. An exception filter such as catch (SqlException ex) when (IsUniqueViolation(ex)) selects only the case the layer understands. Filters are also useful because selection happens before the catch body and preserves clearer debugging behavior than catching everything and conditionally rethrowing.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I keep cancellation distinct from failure: OperationCanceledException tied to the active token is normally allowed to flow to a boundary that understands cancellation rather than being logged as an application error. Wrapping an exception can add domain meaning, but I preserve the original as InnerException and avoid translating so early that useful provider details vanish. Cleanup belongs in using, await using, or finally, not in a catch that only runs for selected failures. In production I define one logging owner per failure path, redact sensitive values, and test status mapping plus stack preservation. Retries happen only around an idempotent operation with classified transient failures, not around an entire request after arbitrary side effects.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using throw ex and erasing the original failure location.
Catching Exception in every layer and logging the same failure repeatedly.
Returning raw exception messages or stack traces to API clients.
Treating cooperative cancellation as an unexpected application failure.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The catch block cannot state how it recovers or translates the failure.
Retries are added without transient classification or idempotency.
Provider exceptions are discarded before diagnostics or mapping can use them.
Cleanup depends on a catch path and is skipped on success or cancellation.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is wrapping an exception useful?
Why can exception filters improve debugging behavior?
Where should an ASP.NET Core application log an unhandled request exception?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

Architecture scenarioHard~12 min

Interview question

Where should exceptions be caught in a .NET application, and what is the difference between throw and throw ex when rethrowing?

Exception boundaries, rethrowing, and exception filters

Preserves failure context, catches only where recovery or translation is possible, and uses filters without hiding unrelated faults.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Exception boundaries, recovery, translation, stack preservation, filters, logging ownership, cancellation, and stable error contracts.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Catching an exception is an ownership decision. The useful question is whether the current layer can recover, add meaningful context, or translate the failure into its own contract.
I catch an exception where I can do something specific: retry a transient operation, translate a dependency error into an application result, release or compensate work, or turn an unhandled request failure into a stable API response. If I only need the same exception to continue, I use throw; inside the catch block because it preserves the original stack trace. throw ex; throws from the current location and loses the original call path. I avoid broad catch blocks in every method because they duplicate logs and hide where recovery actually belongs.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, a repository may let a database timeout propagate with its full technical context, while an application boundary maps a known unique-key violation to a conflict result. Unexpected exceptions reach centralized middleware, which assigns a correlation ID, logs once, and returns a non-sensitive problem response. An exception filter such as catch (SqlException ex) when (IsUniqueViolation(ex)) selects only the case the layer understands. Filters are also useful because selection happens before the catch body and preserves clearer debugging behavior than catching everything and conditionally rethrowing.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I keep cancellation distinct from failure: OperationCanceledException tied to the active token is normally allowed to flow to a boundary that understands cancellation rather than being logged as an application error. Wrapping an exception can add domain meaning, but I preserve the original as InnerException and avoid translating so early that useful provider details vanish. Cleanup belongs in using, await using, or finally, not in a catch that only runs for selected failures. In production I define one logging owner per failure path, redact sensitive values, and test status mapping plus stack preservation. Retries happen only around an idempotent operation with classified transient failures, not around an entire request after arbitrary side effects.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using throw ex and erasing the original failure location.
Catching Exception in every layer and logging the same failure repeatedly.
Returning raw exception messages or stack traces to API clients.
Treating cooperative cancellation as an unexpected application failure.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The catch block cannot state how it recovers or translates the failure.
Retries are added without transient classification or idempotency.
Provider exceptions are discarded before diagnostics or mapping can use them.
Cleanup depends on a catch path and is skipped on success or cancellation.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is wrapping an exception useful?
Why can exception filters improve debugging behavior?
Where should an ASP.NET Core application log an unhandled request exception?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Where should exceptions be caught in a .NET application, and what is the difference between throw and throw ex when rethrowing?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Where should exceptions be caught in a .NET application, and what is the difference between throw and throw ex when rethrowing?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice