In the previous lessons you've learned to make decisions, repeat actions, and classify values, but always assuming the data arrives correctly: a number that really is a number, an index that exists within the array, a book that really is in the catalog. In a real program, that's not guaranteed: a user might type text where a number is expected, someone might try to lend a book that doesn't exist, or divide by a value that turns out to be zero. When something like this happens, C# doesn't just carry on as if nothing happened: it throws an exception, a special object that interrupts the program's normal flow to signal that something has gone wrong. This lesson, the last one in Module 2, teaches you to anticipate these situations and handle them in a controlled way with try/catch/finally, instead of letting the program stop abruptly.

1. What is an exception?
2. try/catch: catching errors
3. finally: code that always runs
4. Throwing your own exceptions with throw
5. Common exception types
6. Catching multiple exception types
7. Best practices with exceptions
8. Full application: lending a book safely

An exception is an object (from a class that derives, directly or indirectly, from System.Exception) representing an error that occurred while the program was running. If nothing is done to handle it, the exception propagates upward until, if no one catches it, the program terminates abruptly and prints an error message to the console along with the call stack (stack trace): the sequence of methods that were executing when the failure occurred.

Running this code, the console would show something similar to:

The goal of this lesson is to keep predictable errors like this one from stopping BiblioTechConsole entirely, and instead react to them in a controlled way.

The try block wraps code that might fail; the catch block defines what to do if it actually does fail.

Unlike the previous example, here the program doesn't stop: the exception is caught, a readable message is displayed, and execution continues on the line after the try/catch block.

You can also access the exception object to look up additional information, such as its Message property:

The optional finally block contains code that runs always, whether the try block finishes successfully or an exception is thrown and caught. It's the usual place to release resources (closing a file, a network connection, or a database connection) that must be closed no matter what happens.

In this example, "Closing the loan log." is always displayed: whether the conversion of "120" succeeds, or fails and the catch catches the error. You'll see finally play a much bigger role in Module 5, when working with files and databases, where properly closing open resources is critical.

Besides catching exceptions thrown by the runtime itself (.NET), your code can throw its own exceptions with throw, to signal an anomalous situation according to BiblioTech's business rules.

throw new ExceptionType("descriptive message") creates a new instance of the specified exception and throws it immediately, interrupting the method's normal execution until some catch block (in this method or in whoever called it) catches it.

.NET provides many ready-made exception classes for common situations. Using the most specific type possible (rather than the generic Exception) helps whoever reads the code — and whoever catches it — understand exactly what went wrong.

A single try block can have several catch blocks, each for a different exception type. C# evaluates the catch blocks from top to bottom and runs the first one whose type matches (or is a base class of) the thrown exception, so the more specific types must always go before the more generic ones.

If FormatException and IndexOutOfRangeException came after catch (Exception ex), they would never run: the C# compiler directly flags that order as an error, because a preceding catch (Exception ex) block would already catch any exception, making the remaining blocks unreachable.

It's also possible to catch several types with the same block, using the when operator to add an extra condition, or simply defining the block for the common base class you're interested in; for most everyday cases, though, one catch per type (as in the previous example) is clearer.

On the first point in the table — not using exceptions for normal flow — if a situation is predictable and frequent (for example, checking whether a text can be converted to a number), it's usually better to use tools like int.TryParse (which you already saw in the variables lesson of Module 1) rather than wrapping int.Parse in a try/catch and waiting for it to fail. Exceptions are meant for exceptional situations, not routine validations:

Let's close the lesson — and the module — with an example that combines several of the ideas covered: searching for a book by title, validating user input, and throwing and catching your own exceptions when a loan operation isn't possible.

Expected output:

Notice how the foreach loop keeps processing every request even if one of them fails: thanks to the try/catch inside the loop itself, an error in one request doesn't prevent the next ones from being processed, and the finally guarantees that the closing message is displayed in all three cases.

• Systematically catching generic Exception: this hides the real error type and makes problems harder to diagnose. Reserve it as a last resort, after the specific types, or to log truly unexpected errors.
• Using exceptions for validations that could be anticipated: if you can check the condition beforehand with an if or with TryParse, do so; don't let the program fail "on purpose" just to catch it afterward.
• Empty catch blocks: catching an exception and doing nothing with it (not displaying a message, not logging it) hides errors that should be fixed; at the very least, report the problem.
• Wrong order of catch blocks: more specific types must always come before more generic ones; otherwise, the compiler will flag the generic block as unreachable.
• Forgetting to release resources: if you open something that needs to be closed (files, connections), use finally or the constructs that already handle it automatically (you'll see this with using in Module 5, when working with files).
• Uninformative exception messages: throw new Exception("Error") doesn't help anyone understand what happened; always include relevant details (which book, which value, which operation).

1. Write a try/catch block that attempts to convert the string "cien" to int with int.Parse, catches the FormatException, and displays a message stating that the input isn't a valid number.

2. Create a local function void ValidateIsbn(string isbn) that throws an ArgumentException with the message "The ISBN cannot be empty." if the isbn parameter is an empty string (""), and otherwise prints "Valid ISBN." to the console. Call the function with "" inside a try/catch that catches the exception and displays its message.

3. Given the array int[] availableCopies = { 2, 0, 3 };, write a try/catch/finally that attempts to access position 5 of the array (which doesn't exist), catches the IndexOutOfRangeException displaying a suitable message, and in the finally displays "Lookup finished." regardless of whether there was an error.

try
{
    int number = int.Parse("cien");
    Console.WriteLine(number);
}
catch (FormatException)
{
    Console.WriteLine("The input isn't a valid number.");
}

Since "cien" can't be converted to int, a FormatException is thrown, and the catch block displays the message "The input isn't a valid number."; the program continues normally after the block.

void ValidateIsbn(string isbn)
{
    if (isbn == "")
    {
        throw new ArgumentException("The ISBN cannot be empty.");
    }

    Console.WriteLine("Valid ISBN.");
}

try
{
    ValidateIsbn("");
}
catch (ArgumentException ex)
{
    Console.WriteLine(ex.Message);
}

Calling ValidateIsbn("") throws the exception with the given message, which the catch catches and displays: "The ISBN cannot be empty.".

int[] availableCopies = { 2, 0, 3 };

try
{
    Console.WriteLine(availableCopies[5]);
}
catch (IndexOutOfRangeException)
{
    Console.WriteLine("That position doesn't exist in the array of available copies.");
}
finally
{
    Console.WriteLine("Lookup finished.");
}

Attempting to access availableCopies[5] (the array only has positions 0, 1, and 2) throws an IndexOutOfRangeException; the catch displays the error message and, afterward, the finally displays "Lookup finished." regardless.

In this lesson you've learned what an exception is and how to catch it with try/catch, how to guarantee that certain code always runs with finally, how to throw your own exceptions with throw to flag broken business rules, the most common .NET exception types, how to catch several types in the right order, and why you shouldn't overuse exceptions for validations that can be anticipated. BiblioTechConsole can now react to invalid data or unforeseen situations without grinding to a halt.

This closes Module 2: Control Structures. You now know how to make decisions with conditionals, repeat actions with loops, classify values with switch, and protect your program from errors with exceptions — all of it, so far, using loose variables, arrays, and local functions inside Main. That way of working starts to show its limits as BiblioTechConsole grows: each book is several loose variables (title, ISBN, availability...) that have to be kept in sync by hand, and each member is just as many more. In Module 3: Object-Oriented Programming you'll learn to model these concepts with classes, grouping data and behavior in a single place: the first step toward BiblioTechConsole ceasing to be a collection of loose variables and starting to look like a real, well-organized application.