Understanding Exception Handling: Strategies and Best Practices for Different System Types

Exception handling is a nuanced and often debated topic for developers, especially when dealing with different system architectures. The article begins by classifying systems and describing how exception strategies should differ for each.

For message‑queue (MQ) consumers, exceptions should rarely be caught locally because the framework needs to manage automatic retries; only non‑idempotent business logic may require direct handling.

In service‑to‑service RPC scenarios, if the business does not involve monetary transactions or critical error distinctions, callers can treat any exception as a generic failure and let the error propagate. When specific error codes are meaningful to the caller, the service should catch the exception, translate it into a well‑defined error code, and return it.

For services that are polled on a schedule, catching exceptions and exposing error codes is essential to indicate whether a retry should occur or the operation should be considered a permanent failure, preventing endless retries that could overwhelm the service.

When providing APIs for mobile (APP) clients, developers must catch exceptions and map them to a rich set of error codes so the front‑end can guide users—such as prompting re‑login or other actions—because mobile interactions are complex.

For PC clients, exception handling can be simpler; error codes similar to HTTP status codes are sufficient, distinguishing server errors, timeouts, or missing methods, with the error message displayed directly to the user.

At the method level, the article discusses the common misuse of try‑catch in every method and argues that exceptions should be thrown upward when they are relevant to the caller’s business logic. Conversely, for low‑level persistence operations, catching exceptions and returning a simple error flag may be more appropriate because callers only need a success/failure indicator.

The author recommends minimizing exception usage by leveraging Java 8’s Optional class to represent optional results, avoiding special sentinel values like -1 , and keeping business flow readable.

When an exception must be propagated through multiple layers—controller, service, or routing—it can be wrapped or re‑thrown so that a centralized handler can assemble error codes and responses, which also aids monitoring systems that filter out non‑business exceptions.

In microservice architectures with long call chains, hiding exceptions hampers troubleshooting; therefore, transparent propagation is advised.

Finally, the article suggests that methods returning ordinary objects should return null on failure, while those returning collections should return an empty collection, aligning with common coding conventions.

The author concludes by hoping the sharing helps readers and invites them to follow the public account for more insights.