学习异常处理：为何创建异常层级结构优于平级定义所有异常？

Great question—this is a common point of confusion when first diving into exception design, but the hierarchy makes a huge difference in how maintainable, flexible, and readable your code ends up being. Let’s use your ATM scenario to break down the key reasons:

1. Flexible Error Handling (Granular or Broad) #

The biggest advantage is that it lets you handle exceptions at different levels of specificity.

• If you only care about "something went wrong during authentication" (and don’t need to distinguish between a wrong card vs. wrong PIN), you can just catch the parent ATMAuthException once. This avoids redundant code where you’d otherwise have to write separate catch blocks for every single flat exception under the authentication umbrella.
• If you do need to handle a specific case (like locking the account after 3 wrong PINs), you can still catch WrongATMPinException specifically, before catching the broader ATMAuthException.

Here’s a code comparison:

Flat Structure (Clunky) #

try {
    atm.login(card, pin);
} catch (WrongATMCardException e) {
    showAuthFailureMessage();
} catch (WrongATMPinException e) {
    showAuthFailureMessage();
    incrementFailedPinAttempts();
}

Hierarchical Structure (Cleaner) #

try {
    atm.login(card, pin);
} catch (WrongATMPinException e) {
    // Handle specific PIN failure logic
    showAuthFailureMessage();
    incrementFailedPinAttempts();
} catch (ATMAuthException e) {
    // Catch-all for any other auth issue (wrong card, expired card, etc.)
    showAuthFailureMessage();
}

2. Clearer Semantics & Business Context #

A hierarchy immediately tells other developers (and future you!) how exceptions relate to your business logic.

• ATMAuthException screams "this error happened when trying to verify the user’s identity"
• WithdrawException says "this error happened when attempting to take money out"

With a flat structure, you just have a list of unrelated-sounding exceptions—someone reading your code would have to guess which ones belong to which workflow.

3. Easy Extensibility (Future-Proofing) #

Suppose next month you need to add a new exception: ExpiredATMCardException.

• With the hierarchy, you just make it a subclass of ATMAuthException. Any existing code that catches ATMAuthException will automatically handle this new exception without any changes.
• With a flat structure, you’d have to either add a new catch block everywhere this could occur, or modify existing logic to include the new exception—both of which are error-prone and violate the "open/closed principle" (code should be open for extension, closed for modification).

4. Consistent Error Reporting & Logging #

Hierarchies make it easier to categorize errors for logging or user messages. For example:

• You can log all ATMAuthException instances under an "Authentication Errors" category, and all WithdrawException instances under "Withdrawal Errors"
• You can show generic messages for parent exceptions ("Authentication failed") and more specific messages for children ("Insufficient balance for withdrawal")

At the end of the day, the hierarchy mirrors how your business logic is structured—grouping related errors together makes your code more intuitive and maintainable in the long run.

内容的提问来源于stack exchange，提问作者Vikram Singh