@NOspy #1 真的有人把错误信息完完全全的塞在返回值里,没救

@qdwang #5 A 方法只需要返回一个 int 类型的数值,正常用 try-catch 设计不需要改变方法的结构入参返回值该怎么样怎么样.
但是如果把错误放到返回值中,那么 int 肯定是必须改,又因为需要详细的错误 code 和 message 那么此时返回值会变成一个含有 code,message,result(正常结果)的对象或者 map
请问你的项目里到处充斥着这种接口,可读性强吗?美观么?每一个错误都重新定义 code 吗?

@iwtbauh #2 不应该直接返回人类可读的错误信息? 应该返回外星人可读的错误信息??????满脑壳的疑问??????????????
@guyeu #3 不同语言不予置评,文中已经说的很明白 try-catch 的作用和意义

@felixlong #19 "3。try...catch 和 if...else 的性能开销在同一数量级" 这句话看不懂吗????

@leeg810312 #6
@vikeria #4 关于异常性能的问题麻烦看这里:https://blog.csdn.net/wenbingoon/article/details/8240862
直接拉到最底下有这么几句话
1。Exception 的性能是差,原因在于 Throwable    fillInStackTrace()方法（）  -----  public synchronized native Throwable fillInStackTrace();
2. 可以通过改写业务异常基类的方法,提升性能
3。try...catch 和 if...else 的性能开销在同一数量级

@murmur #11 那么在方法中将返回值定义成各种对象里面包含对应的状态码和结果就好了吗?试想一个场景,用户购买物品失败如果不使用异常控制则需要在 serverice 方法的返回值中定义 code message result 来告知上层方法本次失败的原因,这种设计是不是比异常控制更恶心?
而用异常控制就很简单了,不会因为需要兼容失败情况而修改方法返回值,只需要捕获不同的异常和异常自定义信息就可以
孰优孰劣,一用便知

很多语言都存在异常处理机制,都是推荐使用 EAFP 方式,因为这样开发者可以注重于开发正常的逻辑而不是时时刻刻考虑 if else 判断,LBYL 方式会导致正常的逻辑穿插各种检查代码反而导致难以读懂
这里有一篇分析你可以看看 http://ju.outofmemory.cn/entry/367391

9120 年了还有人在说不推荐用异常异常性能差呢哈哈哈哈,要是异常性能这么差为啥 jvm 不优化或者不去掉呢?
我推荐使用 2,因为可以准确捕获到除数不能为 0 的异常可以针对的处理,而且并不是每次都为 0 那么每次都多个 if 判断谁的性能差?
jvm 存在的意义就是给你抹除掉在 C 中因为考虑性能而需要在代码中做的种种优化,让开发者更注重于代码的健壮性和语义而不是在开发阶段考虑所谓的"性能",诚然是需要考虑性能但是是需要在并发环境下考虑而不是在这微不足道的 if else 上

数据库唯一约束,分表无法使用
要做严格唯一约束就弄个 redis 之类的内存校验或者从业务上允许重复
单机环境爱咋搞咋搞,就那样

垃圾代码不分国界

@Jackyxiaoc #33 叫 dns chooser,我有发帖介绍

哈啊哈最近刚好找到个类似需求的,不过是 dns 最优解

@fonlan #7 返回多个使用最快的啊

其实用很多人在用的比如用来加速 warframe:https://tieba.baidu.com/p/5628424409?red_tag=0012069433<br>

其实我觉得中文化数学也有搞头!

好顶赞,希望能继续更新下去

从设计方面来讲:前端->后端
设计完成后开发的话:后端写完接口给前端
简单讲就是产品原型->后端接口->前端页面

别想太多,强一致性做不了的
目前的分布式事务解决方案都在出现异常时回滚保证重复执行的幂等
你要是能解决,可以开讲座,不开玩笑

io 密集型把线程数设置为虚拟核心数量,fork/join 框架就是这么做的