Understanding Java Exception Handling: Classification, Bytecode Analysis, Best Practices, and Custom Exceptions

The article begins with an overview of Java exception handling, highlighting common mistakes such as wrapping every method in try‑catch or forgetting to close resources in a finally block, and explains the need for a systematic study of the mechanism.

It then explains the classification of exceptions into checked (compile‑time) and unchecked (runtime) types, describing how the Throwable hierarchy is organized and why finally blocks always execute.

Bytecode analysis is used to illustrate how the JVM implements try‑catch‑finally, showing the transformation from Java source to bytecode instructions such as athrow , exception tables, and the removal of jsr/ret after JDK 1.6. Several concrete cases demonstrate the bytecode generated for simple try‑catch, try‑catch‑finally, and finally blocks containing return statements.

The article introduces try‑with‑resources as syntactic sugar that the compiler expands into nested try‑catch‑finally structures, automatically invoking close() on resources that implement AutoCloseable .

Non‑standard exception handling patterns are listed, such as catching overly generic exceptions, swallowing exceptions, or double‑wrapping them, followed by Alibaba’s Java development guidelines that stress meaningful exception types, avoiding Exception or Throwable , and using business‑specific unchecked exceptions.

Best‑practice recommendations include using try‑with‑resources, throwing specific exceptions, logging with descriptive messages, preferring unchecked exceptions, avoiding Throwable catches, and handling exceptions as late as possible, preferably in a global handler.

For custom exceptions, the article shows how to define an enum ErrorCode with code and message, a SystemException class extending RuntimeException , and a RpcException for RPC‑related errors, illustrating multiple constructors that preserve the original cause.

It then demonstrates a Spring‑Boot AOP global interceptor ( RpcGlobalExceptionAop ) that catches business, RPC, system, and unknown exceptions, logs appropriately, and returns a unified Result object containing code, message, data, and success flag.

For HTTP APIs, three global handling strategies are compared (request forwarding, exception resolvers, and filters), with a detailed example of @RestControllerAdvice that maps BizException , SystemException , and generic Throwable to standardized Result responses.

The conclusion reiterates that Java exceptions are either checked or unchecked, recommends using unchecked exceptions, advises late handling via a global exception processor, and emphasizes encapsulating error information in a consistent result format for callers.