passerbytiny

你只想不与营销斗智斗勇，但你直接硬刚价值规律了——商品的价值（以及再此基础上的价格）都是受供需关系波动的。至于你提到的按需生产，那得生产线变成云生产线、工人变成云工人，才有可能实现。

@shily #13 你这个对楼主来说不解决问题，楼主大概是在最外层有一个统一的异常处理，并不想在抛异常 /错误的地方进行解决。他大概率会写成这样：
static int i;
static {
try {
i = Integer.parseInt("e");
} catch (NumberFormatException nfe) {
throw new Exception(nfe);
}
}

然后编译都过不去，回过头来再表达“我很苦”。

@iFlicker #8 原则上是不能捕获 Error 的，他应该是在最上层捕获了 Throwable，或者不是捕获到而是程序中断后在日志中看到。

@matepi #7 先讲技术，再找理由。

int i = Integer.parseInt(some 变量）才有可能出现异常，而在非演示目的的情况下写出来 int i = Integer.parseInt("e")这样的代码就是沙雕，所以此时抛出的是运行时异常——你无法避免它但是可以解决它。
static int i = Integer.parseInt("e")这明显是沙雕代码； static String someIntStr = "e"; static int i = Integer.parseInt( someIntStr )仍然是沙雕代码； static int i; void initOrUpdate(String aIntStrForInit){ if(Class.i == -1){ Class.i = Integer.parseInt(aIntStrForInit)} }会抛出 NumberFormatException：所以此时前两种情况抛出的是错误——你不能解决它而只能修改源代码区避免它

技术上来说：
一，框架或者库，不管是沙雕还是没考虑到而发生了致命错误，就该给对方抛出个 java.lang.Error，告诉对方这玩意你别解决了，等我解决或者用其它库。而不能是抛出个 java.lang.Exception 或者 java.lang.RuntimeException，告诉对方这玩意你自行解决或者不予理会。作为对方，你应该感谢对方抛了 Error 通知你，而不是抛个 Exception 掩盖致命错误。
二，前人的代码，不管是沙雕、不想干，还是什么乱起八糟的原因，发生致命错误的时候，就该给后人抛出个 java.lang.Error，告诉后人这玩意你别想在你自己的代码中解决了，重构我给你留的代码或者向上级撂挑子吧。作为后人，你应该感谢前人好心提醒你，而不是弄个 Exception 继续糊弄你。

技术上来说还可以简单的一句话：坑就在那里，你要过去就必须填坑；你把 Error 换成 Exception 并不能填坑，反而让你掉进去。

以上大概能解决你对“Never catch Throwable class”的疑问。

下面来说 static int i = Integer.parseInt("e");抛出 Error。

静态变量不是 new 对象的时候由 ClassLoader 设值的，而是 JVM 看到它的时候由 JVM 设值的，此时要是无法设值，那就是 JVM 级别的致命错误。你就算不考虑底层实现，在上层上看，给静态值设置值却设不上去，就像给人取名叫张三但“张三”这两个字有脾气一样，是致命错误。static SomeType someVariable = {一段有可能出错的代码}，这是很危险的行为，抛出 Error 不足为怪。

@Livid 此人（ @fanrong ）引起严重不适

@fanrong 6 天前注册，昨天发第一帖但无回复，今天上来第一条回复就是鸡汤，你要干啥。

@luvxy 看了楼下的回复，现在让你走确实该 2N。现在的情况是大概是不想走辞退程序，给你补 0.5 个月让你辞职。那就耗着吧，不给正式辞退通知书，绝对不走。但是记得，一定不要签字。

你可以
`try{
` int i = Integer.parseInt("e");
`}catch ...
但不可以
`try{
` static int i = Integer.parseInt("e");
`}catch ...

所以前者抛出异常，后者抛出错误。Exception、Error 虽然都继承自 Throwable，但原则上前者捕获后允许处理使其消失，后者捕获后只能做日志、告警而不能处理——必须中断程序或者 5**返回。

6.5 个月，貌似就是 0.5 （提前一个月通知）或者 0.5+1 （让你立马走人）。另外下了辞退通知书，你就必须走人的，除非打官司证明开除通知书无效。补偿有争议，另算，不影响辞退生效。辞退生效后你再去公司，是你自己的自由，但是公司可以让保安（或 JC ）弄你走，并且绝对不会给你一毛工资。

法律的东西，建议还是请教专业人士，不要听人说，也不要听网上说。

还有各种回复“幂等”的，你们在想什么。首先，这是接口调用不是事件订阅，没有重发和无序性，无需考虑幂等；其次，扣余额这种动作你做幂等？ 10 天前扣 1 元跟今天扣 1 元的结果一摸一样？

前方在极短的时间内连续调用你的接口，这个时候你的接口，可能是多节点同时执行，也可能是单节点多线程同时执行，但访问的数据库只有一个：这就是并发场景。这种场景，单节点应用和分布式应用都会出现。

这个场景你如果不考虑，那么可能出现的问题是：一，没上事务，余额表的变动历史将乱成一锅粥；二，上了事务，但在扣余额的时候没做二次验证，余额会被口称负的。

解决方法如下，顺序是从简单到复杂，所有方法都要先有事务（单节点事务）：
一、乐观锁，只适合单节点应用。这个太常见了，而且你也不是单节点应用，就不细说了。
二、实时动态扣费，适合订单模块（不是你的模块）并发量不是特别高的情况。你在扣费的时候不直接扣，先去查下当前余额，如果扣完不为负，再扣费。你的接口的返回结果不是 void，也不是 true/false，而是一个对象，包含这些字段：是否扣款成功、扣费前的实际余额、扣费后的实际余额。
三、最终一致性，适合订单模块超高并发量的情况。直接扣费，返回结果总是成功，如果扣成负的了，发事件通知，让其他模块去做补偿（或者啥也不干就允许余额为负，或者再通知订单模块去取消订单）。

最后说一句，看见分布式事务或者分布式锁的回复，请直接忽略，这是老早就被淘汰的技术。