yoklainterview sim
ProgressHistory

Backend Csharp Exceptions Interview Questions

75 verified Backend Csharp Exceptions interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Csharp ExceptionsDifficulty 1
try
{
    Console.WriteLine("A");
    throw new InvalidOperationException();
}
finally
{
    Console.WriteLine("B");
}

What is printed before the exception propagates out of this code block (assuming nothing catches it further up)?
  • aB then A
  • bA then B✓
  • cOnly A (finally is skipped since no catch)
  • dOnly B (A is buffered and lost since exception was thrown)
Explanation:The try block runs first, printing "A", then throws. Before the exception can propagate further up the call stack, the finally block always runs, printing "B". Only after that does the exception continue propagating.
Csharp ExceptionsDifficulty 2
try
{
    File.ReadAllText("data.txt");
}
catch (Exception e)
{
    Console.WriteLine("generic: " + e.Message);
}
catch (FileNotFoundException e)
{
    Console.WriteLine("specific: " + e.Message);
}

What happens when you try to compile this?
  • aCompiles fine; FileNotFoundException block is simply unreachable at runtime but no error at all, since the compiler simply reorders unreachable branches out of the generated IL
  • bCompiles fine and FileNotFoundException catches first since compiler reorders catch blocks by specificity automatically even though catch blocks are normally matched strictly in the order they are written in source
  • cRuntime error only when a FileNotFoundException is actually thrown; the compiler cannot detect this ordering issue and this ordering mistake would silently ship to production undetected until it actually happened
  • dCompile-time error: a general catch clause (Exception) appears before a more specific one (FileNotFoundException), which C# disallows because the specific catch would never be reached✓
Explanation:C# requires catch clauses to be ordered from most specific to least specific. Since FileNotFoundException derives from Exception, placing catch (Exception) first makes the later catch (FileNotFoundException) unreachable, and the compiler rejects this with a compile-time error rather than silently allowing dead code.
Csharp ExceptionsDifficulty 2
Which statement about the .NET exception class hierarchy is correct?
  • aException is the root of the hierarchy; SystemException and ApplicationException are both subclasses of Exception, and the modern convention for custom exceptions is to derive directly from Exception rather than ApplicationException✓
  • bAll exceptions must derive from SystemException; deriving directly from Exception is not allowed and any attempt to derive a class straight from Exception is rejected by the compiler with an error
  • cApplicationException is the root class that all custom, user-defined exceptions must inherit from in the same way java.lang.Throwable anchors exceptions in some other object-oriented languages
  • dOnly exceptions thrown by the CLR itself can derive from Exception; user-defined exceptions must implement the IException interface instead a design mirroring how some other frameworks require exceptions to implement a marker interface
Explanation:Exception is the base class of the entire hierarchy. SystemException is used (mostly) for exceptions defined by the runtime/BCL; ApplicationException was originally intended for user-defined exceptions but its use is now discouraged in favor of deriving custom exception types directly from Exception.
Csharp ExceptionsDifficulty 1
In a try/catch/finally block, when does the finally block run?
  • aOnly if an exception is thrown and caught by a matching catch block and finally is entirely skipped for exceptions that propagate unhandled past the enclosing method
  • bOnly if no exception is thrown at all which would make finally functionally redundant with just writing code after the try/catch block
  • cAlways, whether or not an exception was thrown, and whether or not it was caught✓
  • dOnly if there is no catch block present for that try which is a common misconception since finally is actually independent of whether catch exists at all
Explanation:The whole point of finally is that it runs unconditionally on the way out of the try/catch, regardless of whether an exception occurred, was caught, or the block exited normally via return.
Csharp ExceptionsDifficulty 2
try
{
    DoWork();
}
catch (Exception ex)
{
    Console.WriteLine("general: " + ex.Message);
}
catch (InvalidOperationException ex)
{
    Console.WriteLine("specific: " + ex.Message);
}

What happens when this code is compiled?
  • aIt compiles fine, and the InvalidOperationException catch block runs whenever that specific exception type is thrown
  • bCompile error (CS0160): the InvalidOperationException catch block is unreachable because the Exception catch above it already handles every exception type, including InvalidOperationException✓
  • cIt compiles, but the InvalidOperationException catch is dead code that the compiler silently ignores at runtime with no error or warning
  • dIt throws a runtime exception, "unreachable catch clause", the first time InvalidOperationException is thrown
Explanation:C# requires catch blocks to be ordered from most specific to least specific. Since InvalidOperationException derives from Exception, a catch(Exception) block placed before catch(InvalidOperationException) would make the second block unreachable — the compiler rejects this with error CS0160, not a runtime error.
Csharp ExceptionsDifficulty 3
void Process()
{
    using var r = new Resource();
    Console.WriteLine("working");
    if (DateTime.Now.Ticks % 2 == 0)
        return;
    Console.WriteLine("more work");
}

Using a C# 8 "using declaration" (no braces) instead of a using block, when is r.Dispose() called?
  • aAt the end of the enclosing block (here, the method), regardless of whether it exits via the final closing brace or an early return✓
  • bImmediately after the line it's declared on, before "working" is printed since C# evaluates using declarations eagerly at the point of their own statement rather than at scope exit
  • cOnly when the method reaches its final closing brace normally; an early return skips disposal which would make using declarations behave differently from stacked using blocks wrapping the same code
  • dNever automatically — using declarations require an explicit using block with braces to trigger disposal which would make the using keyword pointless to write without braces in the first place
Explanation:A using declaration ties disposal to the end of the enclosing scope (the method body in this case), not to a specific line. It fires whether the method exits through its final brace or through an early return, exactly like a using block would if it wrapped the whole rest of the method.

By specialization

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

By seniority

Backend JuniorBackend MidBackend Senior

Other fields

FrontendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3300-question Backend bank.

Start interview