package com.ruoyi.common.core.service;
|
|
/**
|
* 模板模块被关闭时，访问模板能力的调用会抛出本异常。
|
*
|
* <h3>为什么需要它（而不是复用 {@code ServiceException}）</h3>
|
* {@code ServiceException} 是 <b>final</b> 的（见 {@code com.ruoyi.common.exception.ServiceException}），
|
* 既不能继承、也没有实现任何接口，因此无法用"子类 / 标记接口"做到<b>精确捕获</b>。
|
* 而本异常的关键用途恰恰是精确捕获：
|
* <pre>
|
* try {
|
* HeLibrary lib = templateFacade.findHeLibraryById(id);
|
* ...
|
* } catch (TemplateModuleDisabledException e) {
|
* // 模板被关闭 —— 只跳过"取模板内容"这一段，随访主流程照常继续
|
* }
|
* </pre>
|
* 如果改用 {@code ServiceException}，调用方只能用 {@code catch (ServiceException e)}
|
* 或比对 message 文本：前者会把<b>别人的</b>业务异常一起吞掉，
|
* 后者会在改文案时静默失效。两者都是隐患，所以这里单独立一个类型。
|
*
|
* <h3>HTTP 路径上的表现</h3>
|
* 本异常是 {@link RuntimeException}，会被 RuoYi 的全局异常处理器
|
* {@code GlobalExceptionHandler#handleRuntimeException} 捕获并原样返回
|
* {@code e.getMessage()}，因此前端拿到的仍是<b>明确的业务提示</b>，不是"系统异常"。
|
*
|
* <h3>与 {@code TemplateAvailabilityInterceptor} 的分工</h3>
|
* <ul>
|
* <li><b>HTTP 端点</b>（66 个模板管理接口）：由 {@code TemplateAvailabilityInterceptor}
|
* 拦截，抛的是 {@code ServiceException} —— 与满意度/出入院/宣教模块完全一致，刻意不改；</li>
|
* <li><b>跨模块调用</b>（门面）：抛本异常，供调用方精确降级。</li>
|
* </ul>
|
* 两者<b>文案一致</b>（同一个常量），只是类型不同：一个是给 HTTP 调用方看的，
|
* 一个是给 Java 调用方 catch 的。
|
*
|
* @see com.ruoyi.template.api.TemplateFacade
|
*/
|
public class TemplateModuleDisabledException extends RuntimeException {
|
|
private static final long serialVersionUID = 1L;
|
|
public TemplateModuleDisabledException(String message) {
|
super(message);
|
}
|
|
public TemplateModuleDisabledException(String message, Throwable cause) {
|
super(message, cause);
|
}
|
}
|
