定义 cacheexception 需要继承 java.lang.exception，并显式提供包含消息和根因异常的构造函数。这样在抛出异常时，既能通过 getmessage() 获取描述信息，也能通过 getcause() 保留原始的堆栈跟踪，便于排查缓存读写失败的具体原因。
如何设计构造函数以支持链式异常
必须实现至少两个构造函数：一个接受字符串消息，另一个同时接受消息和 Throwable 类型的 cause。这是为了兼容不同场景的调用需求，确保在捕获底层异常（如网络超时或序列化错误）时，能将其包装为 CacheException 向上层传递，而不丢失原始错误上下文。
public class CacheException extends Exception {
public CacheException(String message) {
super(message);
}
public CacheException(String message, Throwable cause) {
super(message, cause);
}
}
如何在业务代码中抛出该异常
在具体的缓存操作逻辑中，当检测到键不存在、数据格式错误或 IO 失败时，应使用 throw new CacheException(...) 语句主动抛出实例。开发者需根据实际发生的错误类型，选择传入简单的错误提示或完整的异常链，从而让调用者能够区分是业务逻辑问题还是底层基础设施问题。
立即学习“Java免费学习笔记（深入）”；
// 示例：模拟从 Redis 获取数据失败
try {
String data = redisClient.get("key");
if (data == null) {
throw new CacheException("Key not found in cache");
}
} catch (JedisConnectionException e) {
// 将底层连接异常包装为自定义异常
throw new CacheException("Failed to connect to cache server", e);
}
基于 catch 块中 cause 非空时的具体处理结果
当 CacheException 是通过带 cause 参数的构造函数抛出的时，其 printStackTrace() 输出会包含两层堆栈信息：外层是 CacheException 抛出的位置，内层是原始异常发生的位置。这种结构使得日志分析工具或人工排查时，能直接定位到最底层的故障点，例如具体的数据库连接超时或 JSON 解析错误，而不是仅仅停留在“缓存操作失败”这一层级。
