这是一个创建于 1658 天前的主题，其中的信息可能已经有所发展或是发生改变。
昨天我发了一个一种无 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
奈何前端技术太菜，现在这阶段根本不能用，等秋招过去有时间就完善。
大家觉得这个怎么样？
 | 1 ipwx 2021 年 10 月 10 日 1. 对于在开发阶段能考虑到的、确实可能发生的东西，我一般不抛异常，而是打日志。。。ERROR 级别或者 CRITICAL 级别。 2. 自己系统里面抛出去不处理的异常，一般是你这个程序无法继续执行了。直接往上抛就行。 3. 真的没必要全都包装一下，本来对于 API 的异常，如果是你开发阶段不处理的，那说明它发生的时候，你的代码对此无能为力，应该直接网上 bypass 。只有你预料到 API 会发生的异常，才需要自己处理一下，重新包装或者直接就地打 log 并且做错误处理。 4. 自己的子系统内部和外部，其实你把子系统看做 API，仿照 3) 处理就行。 5. 异常的定位不能靠类型，要靠 stacktrace |
 | 2 copymaster OP @ipwx 日志是必需的，你第一条的不抛异常打日志这怎么处理的，有异常任它崩溃崩溃后收集异常信息？ 我表达的这个主要目的不是定位，而是把手动抛得异常也当作系统的一部分，不是手动抛得就是程序运行超过了边界发生了意想不到的情况。 |
| 有意识的抛异常确实没毛病。不过我的一个 C++ 项目根本没整那么多子类型，统统我的 AppException 扔出去得了。反正有日志级别和 stacktrace 。 不能处理的异常到上一层呀。如果是 webapp 不是有 per-request 的异常日志嘛 |
 | 4 zhzy0077 2021 年 10 月 11 日 事实上楼主你说的 就是绝大多数业务 Java 代码处理异常操作的逻辑 在业务处理层所有的校验出错都抛一个 ApplicationException 然后在 exception handler 里统一做 l10n 之后吐给客户端 |
Select Language