使用动态代理处理异常

目前遇到一个需要try catch的问题,但我又不喜欢用try catch,所以想到了说可以用动态代理,通过切面代码来写,这样可以不写try-catch,为此总结了如下的知识点:

大概是说把异常处理放在切面里面统一进行
不直接写在业务代码里面

就像下面这样

原来是这样的
function xxx(){
try{
会出异常的代码;
}catch(e){
异常处理;
}
}

每个函数里面都套上try-catch好烦啊
所以直接写成这样:
function xxx() throws exceptions{
会出异常的代码;
}

然后在某个地方配置
拦截所有对这个函数的调用
别的代码仍然以为调用的是xxx函数
实际上可能调用的是下面的aop函数
function aop(){
try{
return xxx();
}catch(e){
异常处理;
}
}

延伸一下的话,别的函数调用也可以被拦截
然后由aop函数统一处理
这样对于同一类的异常处理就可以用一套配置处理了
省去了每次都处理的麻烦

另一点,这里的拦截对调用方和被调用方都是透明的
这也就意味着他们不知道被拦截处理了

实际上函数调用就是在一个对象里面调用另一个对象的方法
实际上也就是向另一个对象发送消息
假设这个消息最初从界面产生(比如用户点击了一个按钮)
发送到了控制器层
控制器发送到了服务层
服务发送到了持久化层
持久化读取数据传回给服务层
服务层组织数据传回控制器层
控制器层排版数据返回视图给用户

消息在业务逻辑的管道中传输
而刚才的拦截就好像将管道切开一个面
用一段管道塞入到这里面
而切面前后的逻辑不知道这里多赛了一段管子

这种思想就是面向切面编程
好处是
在不影响原有业务逻辑的情况下
插入新的处理
### JDK 动态代理中的异常处理 在JDK动态代理机制中,当目标对象的方法执行过程中发生异常时,这些异常会被传递给调用者。为了更好地管理这种行为并遵循良好的编程习惯,在设计和实现基于动态代理的应用程序时应考虑以下几个方面: #### 处理已检査异常与未检査异常的区别 对于由被代理实例抛出的已检查(checked)异常,应当确保它们能够在接口定义中声明出来;而对于运行时(unchecked)异常,则不需要这样做。这是因为 unchecked 异常继承自 `RuntimeException` 类或更具体的子类[^3]。 ```java public interface Service { void performTask() throws SpecificCheckedException; // 已检查异常需在此处声明 } // InvocationHandler 实现部分逻辑 @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { try { return method.invoke(realSubject, args); } catch (SpecificCheckedException e) { throw new CustomWrapperException("Error occurred during task execution.", e); // 可能重新包装成另一种形式 } } ``` #### 使用自定义异常进行封装 有时可能希望通过创建特定于应用程序上下文的新异常类型来增强错误消息的信息量。这有助于客户端代码更容易理解发生了什么问题以及如何应对它。如果原始异常不适合暴露给外部使用者,可以通过构造新的异常并将旧的一个作为原因参数传入构造函数内。 #### 日志记录与监控 每当捕获到任何类型的异常时,都应该适当地记录下相关信息以便后续分析。这对于诊断生产环境中发生的难以重现的问题尤为重要。此外还可以集成分布式跟踪工具帮助定位跨服务边界的故障点所在位置。 #### 避免过度宽泛的catch语句 虽然在一个地方集中处理所有可能出现的情况看起来很方便,但这往往会使调试变得更加困难,并掩盖真正应该关注的地方。相反地建议针对每种预期之外的情形分别编写对应的处理器,只捕捉那些确实知道怎么解决或者至少能够给出有意义反馈的对象。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值