@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，而是一个对象，包含这些字段：是否扣款成功、扣费前的实际余额、扣费后的实际余额。
三、最终一致性，适合订单模块超高并发量的情况。直接扣费，返回结果总是成功，如果扣成负的了，发事件通知，让其他模块去做补偿（或者啥也不干就允许余额为负，或者再通知订单模块去取消订单）。

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

@DOLLOR #13 windows 上剪贴板用得太频繁了，大规模无差别监听意义并不大，除非你就用一个密码还记不住。

那么，如果我就是像让人知道我用得就是 win10 不是 win7 呢，我连个开启 UA 的开关都没有。Chrome 最大的问题不是它要干什么，而是它不让用户干什么。

Firefox 保平安。

这就是 Windows 的以其他用户运行程序，我没有隔离运行的需要，但是将来可能用这个来搞 Firefox 的多用户运行。

别管合同工资，难道每次涨工资都要变更一次合同吗，有没有降薪、裁员补偿、竞业补偿的工资基准，是你前 12 个月的平均月平均工资。

在法理上来说，如果公司咬定这 3000 元是扣掉的而不是缓发，那就是降薪。你如果选择拒绝，那么可以解除合同并且公司要按照开除来做 N+1 补偿。

但是呢，公司在年前最后一次发工资的时候扣钱，不是坏到透顶就是确实没钱了，你就算法理上赢了也很难拿到钱，能做得只能是及时止损。

该弄得还得弄，年后直接向公司摊牌形成事实开除，然后仲裁、诉讼走一波，同时找新工作。但是你要先准备几个月的生活存款，因为公司很有可能会改口但同时以公司没钱为由断你工资，那样就成了拖欠工资，你没办法找新工作的。另外摊牌后记得爆名字。

“如果不想太折腾又想……”，你就不用又想，只要你不想折腾，请远离 Android。光一个稳定的 FCM 推送通道，你都得折腾几天并且还折腾不出来。

这种东西，你不能用常规的增删改查思路去做。文档差异化对比的方式，不止是性能问题，一致性也保证不了的。你可以考虑 Event Soucring + CQRS。

@shnily 偷偷的告诉你：注册时候要人脸，那是实名制的需要，这个时候才是爱用用不用滚；银行大额转账的时候要身份证、人脸等，那是为了存下这笔转账的转出人（嫌疑人），以便将来出事的时候好举证（推卸责任）；支付宝大额转账要人脸，同银行；支付宝、微信非转账业务要人脸，这就是要搜集你的脸，没有什么安全理由。

再偷偷的告诉你：所谓认证，不管是账户认证还是实名制认证，必须是首先注册了相关信息，才能在用的时候再次提供信息拿来比对；以前从来没给过脸，突然要你给脸的，绝对不是认证，只可能是嫌疑人留底或搜集信息。

你这种人，就是典型的“被人卖了还帮人数钱”那种。

先说你这个，加班白加+请假扣钱+请假必须给理由，请辞职。

然后再说病假的事，病假属于有薪假（一般给 50%到 80%，运气好的会碰到 100%），所以请病假要有医院，而且得是三甲之上医院，出具得证明。体制外的人无社保或比例太低，去三甲医院花的钱是日薪的 N 倍，还不如请事假去小诊所看病，所以体制外基本只有事假没有病假。

说句不好听的话，正是楼主你现在网上发帖的行为（本质上只是发发牢骚但还会继续用的），助长了它的下限。要是真觉得垃圾，会默默的远离的，连发帖骂一下都没心情的。