Java 中的异常要区分受检查异常和运行时异常，我认为这个机制简直是个败笔？

[qwerthhusn]

受检查的异常需要捕获或者catch吞掉（一般做法是重新包装一个RuntimeException抛出去），在重载一些接口或类的方法时可能必须要catch(包括 lambda 表达式)

1. 其他语言应该基本上没有这样做的
2. 从语义上，其实 Checked Exception 和 Runtime Exception 不好定界，导致不同的框架或第三方库有不同的偏好。举个栗子，Spring 系基本上不会用受检查异常，Jackson 基本上所有 API 都声明了 IOException。
3. 虽然 Checked Exception 会告诉你需要处理这种异常，但是 Runtime Exception 在有些时候你也需要处理，这个就变成了隐藏的雷。而其实更多时候，Checked Exception 其实也不需要做过多的处理，所以代码中有很多catch (EXception ex) { throw new XXXRuntimeException(ex); }

[passerbytiny]

@qwerthhusn 你补充的 fastjson，不好用的原因，除了缺少 Javadoc 外，还有一个原因是 RuntimeException 用多了。作为一个类库，经过良好的测试之后，应该是极少抛出运行时异常的。

顺便告诉我一下我对你的这个 @ 有没有消息提醒。

[qwerthhusn]

@passerbytiny 有，但是感觉今天的消息提醒有时会丢。。。作为一个类库，经过良好的测试之后，应该是极少抛出运行时异常的。这个是 JSON 解析库，是根据用户的输入来的。。。

[passerbytiny]

@qwerthhusn #21 看来我得静等站长的回复了。作为一个 JSON 解析库，当用户输入不正确的时候，应该明确的抛出表示无法解析的异常，或者更明确地抛出表示为什么解析不了的异常，而不应该是 ClassCastException，NullPointerException，IndexOutOfBoundsException 这种原始异常，这是相当不负责任的。此时抛出的异常，虽然是运行时异常，但也应当放到方法签名的 throws 中。

[WalkingEraser]

这两种异常在鼓励 let it crash 的 Erlang(比 Java 大八岁)里，被用不同的抛出方式区分成 throw 型异常、error 异常(还有第三种 exit，表示进程退出)。但实践中，他喵很可能被码畜通配捕获成同一种处理了...还好是绝大部人只会 throw，问题不大。
我个人是喜欢这种区分的，如果规范，能有效说明异常发生频率、场景、严重性、是否可处理恢复等。然而业务码畜主观和客观上不会聊这些的。
归根结底还是码畜的自我修养。

[WalkingEraser]

但在框架或者说接口层面上，Erlang 记得一般会通过不同 API 和注解来告知调用方，所以也挺坑的。后面新出的 Elixir 方言，则会在同个方法名后显示加上!来告知。

[SoloCompany]

checked exception 简而言之就是把异常当正常来设计，语言层面这就是一个烂的设计

你看看 java 8 都被迫引入一个 unchecked io exception 就知道这设计有多烂了

[SoloCompany]

也许有人会争辩一开始就应该把 io exception 设计成 re，但这根本解决不了问题
到最后会发现所有 exception 都应该设计为 re

[wr410]

checkexception 的作用就是告诉你很可能会有意料之内的异常，然后让人家用的时候在这里 try 一下。
runtimeexception 的是意料之外的异常，什么 oom 什么鬼的。
总之请至少让我在进入一个迭代里面的时候知道需不需要 try 起来。

[SuperMild]

知足吧，想想 Golang，几乎每个函数都给你一个 err，而且还无法统一包裹在 try catch 里，必须每个 err 都用 if 来检查……