这种 Java 异常实践怎么样?

2021-10-10 18:28:19 +08:00
 copymaster

昨天我发了一个一种无 HTTPS 的安全通信方式帖子,结果不到半个小时就结贴了,今天我又来推广我的 idea 了,大家来看看这个是不是也无用

事情起因是这样的,对于 java 异常的使用我始终不明白最佳实践是什么,对于 log 中的异常不能确定是自己抛的忘了 catch 还是使用 api 不当造成的,后来我苦思冥想想到了一种 java 异常的实践: 对于程序中考虑到的异常全部都用自定义的异常,每个项目都配置一个根异常类,比如说 XXXAppException 作为这个 app 的根异常,后续异常全部都继承这个。在 Java 领域,无论是 web 还是 Android 都有一个统一接收未 catch 异常的地方,android 的捕捉异常机制好像是 UncaughtExceptionHandler,web spring 也能捕捉所有抛出的未 catch 的异常。我们只需要在异常终点这里辨别抛出的异常是不是 XXXAppException 及其子异常就可以了。如果是,说明这个异常是开发阶段考虑到的,在异常类中我们也可以定义一些该异常的相关信息,比如异常码,提示信息等;如果不是,可以马上把这个异常报告给开发人员,这个异常是开发阶段没考虑到的,会酿成什么事故还不能确定,需要开发人员立即处理。

为了实践这个理论,我还做了一个生成异常类的项目

https://github.com/helloliuyiming/java-exception-class-generator

奈何前端技术太菜,现在这阶段根本不能用,等秋招过去有时间就完善。

大家觉得这个怎么样?

2097 次点击
所在节点    分享创造
4 条回复
ipwx
2021-10-10 18:45:16 +08:00
1. 对于在开发阶段能考虑到的、确实可能发生的东西,我一般不抛异常,而是打日志。。。ERROR 级别或者 CRITICAL 级别。
2. 自己系统里面抛出去不处理的异常,一般是你这个程序无法继续执行了。直接往上抛就行。
3. 真的没必要全都包装一下,本来对于 API 的异常,如果是你开发阶段不处理的,那说明它发生的时候,你的代码对此无能为力,应该直接网上 bypass 。只有你预料到 API 会发生的异常,才需要自己处理一下,重新包装或者直接就地打 log 并且做错误处理。
4. 自己的子系统内部和外部,其实你把子系统看做 API,仿照 3) 处理就行。
5. 异常的定位不能靠类型,要靠 stacktrace
copymaster
2021-10-10 19:09:33 +08:00
@ipwx 日志是必需的,你第一条的不抛异常打日志这怎么处理的,有异常任它崩溃崩溃后收集异常信息?
我表达的这个主要目的不是定位,而是把手动抛得异常也当作系统的一部分,不是手动抛得就是程序运行超过了边界发生了意想不到的情况。
ipwx
2021-10-10 20:07:24 +08:00
有意识的抛异常确实没毛病。不过我的一个 C++ 项目根本没整那么多子类型,统统我的 AppException 扔出去得了。反正有日志级别和 stacktrace 。

不能处理的异常到上一层呀。如果是 webapp 不是有 per-request 的异常日志嘛
zhzy0077
2021-10-11 00:11:35 +08:00
事实上楼主你说的 就是绝大多数业务 Java 代码处理异常操作的逻辑 在业务处理层所有的校验出错都抛一个 ApplicationException 然后在 exception handler 里统一做 l10n 之后吐给客户端

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/806870

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX