The detected exception is used to recoverable scenarios to avoid abuse to prevent increased complexity; 2. Throw specific exception types instead of generalized exceptions to improve readability and maintenance; 3. The exception message should be specific, contains parameter values and does not expose sensitive information; 4. Errors should be thrown as soon as possible, and the capture should be delayed to a position that can be processed; 5. It is prohibited to ignore exceptions, logs should be recorded or try-with-resources should be used; 6. All AutoCloseable resources must be managed with try-with-resources; 7. Convert exceptions at abstract boundaries and retain root causes; 8. Exceptions or return should not be thrown in finally blocks to avoid covering up exceptions; 9. Custom exceptions should be immutable and provide complete constructors and getters; 10. After catching exceptions, logs must be recorded or reported to monitor to avoid silent failure. Exception handling is a key design method for program robustness.

Exception handling is a key but often misused part of Java programming. Good exception handling not only improves the robustness of the program, but also makes debugging and maintenance more efficient. The following are Java exception handling best practices based on Effective Java and actual development experience.

1. Prefer checked exceptions only if recovery is possible

The detected exception (such as IOException ) is forced to handle by the caller, which is suitable for scenarios where the caller can reasonably recover . For example, when a file read fails, the user can choose to try again or select another file.

 try {
    fileService.loadConfiguration("config.xml");
} catch (FileNotFoundException e) {
    logger.warn("Config not found, using defaults.");
    useDefaultConfig();
}

Do not abuse checked exceptions : If the caller cannot take meaningful recovery measures, the runtime exception should be used. Excessive use of detected exceptions can increase code complexity, forcing developers to write meaningless code that "swallows exceptions" or "prints things".

2. Throw appropriate exception types to avoid generalization

Don't always throw Exception or RuntimeException . Semantically explicit exception classes should be used or defined.

? Good practice:

 throw new InvalidOrderException("Order total must be positive.");

? Avoid:

 throw new RuntimeException("Invalid order");

benefit :

• Callers can capture and process targetedly
• Improve code readability and maintainability
• Easy to test and log analysis

It is recommended to define your own exception level for the module, such as:

 AppException
├── DataAccessException
├── ValidationException
└── ServiceException

3. Provide clear exception information

Exception messages are the first clue to debugging. Ensure that the message is specific, complete and operational .

? Recommended:

 throw new IllegalArgumentException(
    String.format("Age %d is out of valid range [0, 120]", age)
);

? Avoid:

 throw new IllegalArgumentException("Invalid age");

Additional suggestions :

• Includes relevant parameter values
• Do not expose sensitive information (such as passwords, keys)
• Use parameterized messages to avoid string stitching performance issues (can be combined with logging framework)

4. Throw as soon as possible and delay capture

• Throw as early as possible : Throw it immediately when an error is detected to avoid the problem propagating to the deep call stack.

   public void processUser(User user) {
      if (user == null) {
          throw new IllegalArgumentException("User cannot be null");
      }
      // ...
  }

• Delay capture : Recapture where exceptions are capable of handling, rather than try-catch at each layer.

  ? Error practice:

   public void saveUser() {
      try {
          dao.save(user);
      } catch (SQLException e) {
          throw new RuntimeException(e); // Package but meaningless}
  }

  ? Correct way: Let the upper-level service or controller handle persistent layer exceptions uniformly.

5. Don't ignore exceptions

The following code is a common anti-pattern:

 try {
    inputStream.close();
} catch (IOException e) {
    // Empty catch block!
}

Correct way to do it :

• If it really doesn't work, at least log the log:

   } catch (IOException e) {
      logger.debug("Failed to close input stream", e);
  }

• Or use try-with-resources to automatically manage resources (recommended):

   try (InputStream is = new FileInputStream("file.txt")) {
      // Automatically close, no manual catch close exception}

6. Use try-with-resources to manage resources

All resources that implement AutoCloseable (such as streams, connections) should use try-with-resources.

? Recommended:

 try (FileInputStream fis = new FileInputStream("data.txt");
     BufferedReader br = new BufferedReader(new InputStreamReader(fis))) {
    return br.readLine();
}
// Automatically call close(), including exceptions

? Avoid traditional try-finally:

 FileInputStream fis = null;
try {
    fis = new FileInputStream("data.txt");
    // ...
} finally {
    if (fis != null) fis.close(); // Exception may be thrown and difficult to handle}

7. Exception Translation

At abstract boundaries (such as the DAO layer), the underlying exception should be converted to higher-level abstract exceptions to avoid exposing implementation details.

 public User findUser(int id) {
    try {
        return jdbcTemplate.queryForObject(SQL, User.class, id);
    } catch (DataAccessException e) {
        throw new UserServiceException("Failed to load user with id: " id, e);
    }
}

Note : Always keep the original exception as a cause to facilitate the tracking of the root cause.

8. Avoid throwing exceptions or return in finally blocks

The return in finally block will override the return value in try and even mask the exception.

? Danger code:

 try {
    throw new RuntimeException("Try exception");
} finally {
    return "from finally"; // Swallow the exception!
}

? Correct way:

• Don't return in finally
• If you have to perform an operation, make sure that no exception is thrown, or handle it properly

9. Custom exceptions should be immutable and provide a complete constructor

When defining custom exceptions, follow the standard pattern:

 public class InsufficientFundsException extends Exception {
    private final double balance;
    private final double amount;

    public InsufficientFundsException(double balance, double amount, String message) {
        super(message);
        this.balance = balance;
        this.amount = amount;
    }

    // Provide getter, not setter (immutable)
    public double getBalance() { return balance; }
    public double getAmount() { return amount; }
}

10. Logs and monitoring: Exceptions are not reasons for silent failure

• After the exception is caught, the log should be logged unless it is fully restored.
• On critical paths, consider reporting exceptions to the monitoring system (such as Sentry, ELK)
• Avoid repeated printing of logs (such as printing in multi-layer catch)

Basically that's it. Exception handling is not a "bottom-up" technique, but a design language - it tells you under what circumstances the program will fail and how you plan to deal with it. Only by writing exception handling can the code be truly "solid".

The above is the detailed content of Effective Java Exception Handling Best Practices. For more information, please follow other related articles on the PHP Chinese website!