6.10.6: Handling Multiple Exceptions: Vending Machine Example.: 5 Real Examples Explained

Ever tried to buy a snack from a vending machine that just won’t cooperate?
You press “A1”, the screen flashes “OUT OF STOCK”, then “INVALID COIN”, and finally the machine just swallows your money. In that split‑second panic you’re not really thinking about code—you're thinking about your craving.

But that exact chaos is what happens in software when you try to juggle several things that can go wrong at the same time. In Java, C#, Python, or any language that supports exceptions, handling multiple exceptions cleanly is the difference between a graceful “please try again” and a crash that leaves users staring at a blank screen Surprisingly effective..

Easier said than done, but still worth knowing.

Below is the deep dive you’ve been waiting for: a full‑blown walk‑through of handling multiple exceptions using the classic vending‑machine scenario. We’ll unpack why it matters, how the language mechanics work, the pitfalls most developers fall into, and the real‑world tricks that actually keep your code readable and reliable.

What Is “Handling Multiple Exceptions”?

When a method can fail in more than one way, you can either catch each failure separately or lump them together. Think of the vending machine: a user might insert a bad coin, select an empty slot, or the machine could simply be out of power. Each of those is a distinct error condition, and each needs its own response Nothing fancy..

In code, those conditions become exception types (e.So g. , InvalidCoinException, OutOfStockException, PowerFailureException). Handling multiple exceptions means you anticipate each of those types and write logic that reacts appropriately—whether that’s returning change, suggesting another product, or logging a critical failure It's one of those things that adds up..

The short version: you’re building a safety net that’s shaped differently for each kind of fall.

Why It Matters / Why People Care

Real‑world impact

A vending machine that just “fails” and takes your money is a PR nightmare. In software, an unhandled exception does the same thing: it crashes the app, loses data, and erodes trust. Users don’t care about stack traces; they care about the experience.

Maintenance headaches

If you catch everything with a generic catch (Exception e) block, you lose the ability to differentiate problems later. Debugging becomes a guessing game, and adding new error cases later turns into a mess of nested ifs.

Compliance and safety

Some industries (banking, medical devices) require you to log specific error types for audit trails. Throwing a blanket exception could land you in legal trouble Small thing, real impact. Turns out it matters..

How It Works (or How to Do It)

Below is a step‑by‑step guide that shows the vending‑machine example in Java‑style pseudocode. The concepts translate to C#, Python, or any language with a similar exception model Simple, but easy to overlook..

### 1. Define Specific Exception Classes

class InvalidCoinException extends Exception { }
class OutOfStockException extends Exception { }
class PowerFailureException extends Exception { }

Why separate classes? Practically speaking, because each one carries its own meaning and can hold extra data (e. Plus, g. , the amount of change needed for InvalidCoinException) Simple, but easy to overlook. And it works..

### 2. Throw Exceptions Where They Belong

public void insertCoin(Coin coin) throws InvalidCoinException {
    if (!coin.isValid()) {
        throw new InvalidCoinException("Coin value not recognized");
    }
    // add to credit...
}

The insertCoin method knows only about coin validity, so it throws only that exception. No need to worry about stock here Small thing, real impact. No workaround needed..

### 3. Catch Multiple Exceptions Separately

try {
    machine.insertCoin(userCoin);
    machine.selectProduct("A1");
    machine.dispense();
} catch (InvalidCoinException e) {
    displayMessage("Please insert a valid coin.");
    returnCoin(userCoin);
} catch (OutOfStockException e) {
    displayMessage("Sorry, that item is out of stock.");
    // maybe suggest alternatives
} catch (PowerFailureException e) {
    logCritical(e);
    displayMessage("Machine offline. Please try later.");
}

Notice the order matters: more specific exceptions first, then broader ones. If you added a generic catch (Exception e) at the top, the specific blocks would never run And it works..

### 4. Use Multi‑Catch (Java 7+)

If two exceptions share identical handling logic, you can collapse them:

catch (InvalidCoinException | OutOfStockException e) {
    displayMessage(e.getMessage());
    // common recovery steps
}

Python’s equivalent is a tuple in the except clause, and C# lets you filter with when.

### 5. Finally Block for Cleanup

Regardless of which exception fires, you often need to release resources (close a DB connection, reset the coin hopper, etc.):

finally {
    machine.resetTempState();
}

That guarantees the machine isn’t left in a half‑open state It's one of those things that adds up..

### 6. Propagate When You Can’t Do Anything

Sometimes the UI layer can’t fix a power failure; it should just bubble it up:

public void startTransaction() throws PowerFailureException {
    if (!machine.isPowered()) {
        throw new PowerFailureException("No power");
    }
    // continue...
}

Higher‑level code decides whether to retry, alert a technician, or shut down gracefully.

Common Mistakes / What Most People Get Wrong

1. Catching Exception everywhere – It looks tidy, but you lose granularity. The machine will “handle” a power failure the same way it handles a bad coin, which is absurd.

2. Swallowing exceptions silently – catch (Exception e) {} may compile, but you’ve just hidden a bug. Users get no feedback, and you have no logs.

3. Wrong order of catch blocks – Putting a generic catch before a specific one makes the specific block unreachable. The compiler will even warn you in most languages.

4. Using exceptions for control flow – Throwing an OutOfStockException every time a user picks a sold‑out snack feels like overkill. A simple boolean check could suffice, unless you need stack traces for audit.

5. Forgetting to clean up – Not resetting the coin slot after an InvalidCoinException can cause the next user’s coin to be misread Simple, but easy to overlook..

6. Duplicating error messages – Hard‑coding the same string in multiple catch blocks leads to inconsistency. Centralize messages or use a resource file Surprisingly effective..

Practical Tips / What Actually Works

• Map each business rule to its own exception. If “coin too small” and “coin too large” need different UI messages, give them separate classes.

• use inheritance. Create a base VendingMachineException and let all specific exceptions extend it. You can then catch the base for generic logging while still handling specifics.

  catch (VendingMachineException e) {
      logError(e);
  }
  

• Wrap third‑party exceptions. If the payment module throws IOException, wrap it in InvalidCoinException so the rest of your code stays domain‑focused.

• Use exception filters (C#) or conditional catches (Python) to keep the catch block small but still differentiate:

  catch (VendingMachineException e) when (e is PowerFailureException)
  {
      // power‑specific handling
  }
  

• Create a helper method for UI feedback. Instead of repeating displayMessage(...) in every catch, call handleUserError(e) which decides the right wording Worth keeping that in mind..

• Test each path. Write unit tests that deliberately trigger each exception. Mock the hardware layer so you can simulate “coin jam” or “out of power” without a real machine.

• Log with context. Include the product code, coin value, and timestamp in your logs. When a PowerFailureException appears, you’ll instantly know if it happened during a dispense or a simple credit check.

• Consider retry logic. A transient PowerFailureException might resolve after a short wait. Use exponential back‑off rather than immediate failure.

FAQ

Q: Do I really need a custom exception for every tiny error?
A: Not always. If two errors share the same UI response and recovery steps, a single exception type is fine. The rule of thumb: create a new class when you need distinct handling or extra data Simple as that..

Q: How do I handle exceptions thrown from async operations in a vending‑machine app?
A: Propagate them with await and wrap them in a domain‑specific exception if needed. Most async frameworks will still let you use try/catch around the awaited call.

Q: What if the machine runs out of change while returning money?
A: Throw a ChangeUnavailableException. Catch it at a higher level where you can either display “Please contact support” or trigger a service alert.

Q: Is it okay to log the stack trace for user‑visible errors?
A: Log it internally, but never expose the raw trace to the user. Show a friendly message; keep the technical details in your log files.

Q: Can I use a single catch block with a list of exceptions in Python?
A: Yes. Use a tuple: except (InvalidCoinError, OutOfStockError) as e:. Inside, you can inspect type(e) if you need different messages Small thing, real impact..

That vending machine that eats your money isn’t just a metaphor—it’s a concrete reminder that every error path needs its own care. By defining precise exception types, catching them in the right order, and cleaning up after each failure, you turn a frustrating “machine error” into a smooth “please try again” experience.

So the next time you write a method that could go wrong in three different ways, think of the coin, the snack, and the power cord. Handle each exception like you’d handle each real‑world hiccup: with a clear, specific response, a tidy cleanup, and a log that future you can read without pulling your hair out. Happy coding, and may your machines always give you the change you expect Simple as that..