Master Java Exception Handling: Best Practices, Bytecode Insights & Custom Exceptions

Overview

The author studied Java exception handling standards, especially Alibaba's Java development guidelines, to deepen understanding and share practical insights for developers facing similar confusion.

Java Exception Mechanism

Java exceptions are divided into checked exceptions (compile‑time) and unchecked exceptions (runtime). Checked exceptions must be declared or caught, while unchecked exceptions do not require explicit handling.

Exception Classification

Understand the difference between checked and unchecked exceptions.

Analyze why finally blocks always execute from a bytecode perspective.

Identify non‑standard exception handling cases.

Learn best‑practice guidelines.

Determine when to throw or catch exceptions in a project.

Bytecode Analysis of Exception Handling

Try‑Catch Bytecode (JDK 1.8)

The athrow instruction throws an exception object; the JVM searches the exception table for a matching handler. If found, execution jumps to the handler; otherwise, the stack frame is popped and the exception propagates upward.

Try‑Catch‑Finally Bytecode

Adding a finally block introduces an "any" entry in the exception table, ensuring that code in the finally region executes regardless of how the try block terminates.

Why finally Always Executes

The compiler duplicates the finally code after each possible exit point (normal return, exception, or return in finally), guaranteeing its execution.

Return in finally

public int getInt() { int i = 0; try { i = 1; return i; } finally { i = 2; return i; } }

When a return appears in finally, it overrides any previous return, so developers should avoid returning from finally.

Try‑With‑Resources

Introduced in JDK 1.7, try (resource) automatically closes resources, eliminating manual finally cleanup. The compiler translates it into nested try‑catch‑finally blocks that invoke close() and suppress secondary exceptions.

Non‑Standard Exception Handling Cases

Catching all exceptions without distinction.

Missing specific exception types.

Losing exception information during propagation.

Improper exception wrapping.

Using checked exceptions for business logic.

Best Practices

Prefer try‑with‑resources for resource cleanup.

Throw specific exceptions, not generic Exception.

Log descriptive error messages, including input/output when calling external services.

Catch the most specific exception possible.

Avoid catching Throwable unless necessary.

Never swallow exceptions; always handle them.

Either log or rethrow, but not both.

Preserve the original cause when wrapping exceptions.

Avoid checked exceptions for custom business errors.

Catch exceptions as late as possible, preferably at the top layer.

Centralize logging to the top layer to prevent duplicate logs.

Project Practices

Custom Exceptions

Define an ErrorCode enum with a code and message, then create custom unchecked exceptions (e.g., SystemException, BizException, RpcException) that extend RuntimeException. Include constructors for message, cause, and error code.

public enum ErrorCode { SYSTEM_ERROR("A000", "System error"), BIZ_ERROR("B000", "Business error"), NO_PERMISSION("B001", "No permission"); /* getters and setters */ }

Using Exceptions

Throw a specific exception when a business rule is violated, e.g., throw new BizException(ErrorCode.NO_PERMISSION);. Distinguish between business exceptions (user‑recoverable) and system exceptions (developer‑recoverable).

Global Exception Handling for RPC

Wrap RPC results in a Result object containing code, message, data, and success. Implement an AOP advice that catches BizException, RpcException, SystemException, and generic Throwable, logging appropriately and returning a failure Result.

@Around("pointcut()") public Object handleException(ProceedingJoinPoint jp) { try { return jp.proceed(); } catch (BizException e) { log.warn("Biz exception", e); return Result.fail(e.getCode(), e.getMessage()); } catch (RpcException e) { log.error("RPC exception", e); return Result.fail(e.getCode(), e.getMessage()); } catch (SystemException e) { log.error("System exception", e); return Result.fail(e.getCode(), e.getMessage()); } catch (Throwable e) { log.error("Unknown exception", e); return Result.fail(e.getMessage()); } }

Global Exception Handling for HTTP (Spring Boot)

Use @RestControllerAdvice with @ExceptionHandler methods to convert exceptions into Result responses.

@ExceptionHandler(BizException.class) public Object handleBiz(HttpServletRequest req, BizException e) { log.warn("Biz exception: " + e.getMessage(), e); return Result.fail(e.getCode(), e.getMessage()); }

Conclusion

Understanding Java's exception mechanism—from bytecode to best‑practice guidelines—helps developers write cleaner, more maintainable code. Prefer unchecked exceptions, use try‑with‑resources, centralize handling with global interceptors, and encapsulate error information in a unified Result model.