反对 try{}catch (e){}的进来， B 君已经是全群公敌！

[minggeJS]

（提醒：我不是来问问题的，我已经有自己答案！）
A 君和 B 君各自用 JS 做一个简单的需求:

function test(foo){
var obj= new foo();

obj.wo.ok.arr.push("帅哥");

return obj;


}

当 foo 传入错误参数时 程序是肯定是报错的！ obj.wo 无法索引到时，也同样是报错的
现在 A 君和 B 君分别采用不同的方法
-------------------------------------------------------------
A 君采用的方法是：

function test(foo) {
if (typeof foo == "function") {
var obj = new foo();
if (obj.wo && obj.wo.ok && Object.prototype.toString.call(obj.wo.ok.arr) == "[object Array]") {
obj.wo.ok.arr.push("帅哥");
return obj;
}
}
return false;
}
----------------------------------------------------------------------------------------
B 君采用的方法是：
function test(foo) {
try{
var obj = new foo();
obj.wo.ok.arr.push("帅哥");
return obj;
}catch (e){}
return false;
}



结果 B 君成为了全群公敌，及取笑的对象， A 君和 B 君各不相让， A 君更是大骂 B 君：“你百度看看看，你用 TRY 是菜鸟的行为， TRY 效率很差的，应该尽量避免使用 TRY ”。
B 君一向按自己的原则做事， B 君不相信百度，坚持自己的 TRY 立场,B 君觉得自己的 TRY 用得完全合理，一气之下愤然离群！

现在问大家：上面两段你觉得 A 君和 B 君的代码 谁的效率最高呢！
(稍后公布答案）！

答案参考： https://github.com/drduan/minggeJS/issues/201

@jarlyyn A 君 B 君代码只是一个演试效果，我并没有说用 try 就不能用 if 了，我从头到尾没这样说

在实际开发中， B 君可以 TRY 再配合适当 if 进行判断， 而 A 君呢，只能 IF 又再多 if 一句。
最后 A 君的代码，变得又长又没有效率，而 B 君的代码大不了再多一句 if 。一样是轻巧型代码

所以到最后 B 君始终是最后胜利者

retun false 只是为了让演试具有立体效，为何要捉住 retun false 不放！何必呢

function test(foo) {
try{
var obj = new foo();
obj.wo.ok.arr.push("帅哥");
return obj;
}catch (e){
return "我要 DEBUG ："+e
}

}

[minggeJS]

该事件是真人真事！ A 和 B 其中一个我本人

[will0404]

两种都用过 用 A 比较多 楼主肯定是 B 吧

[minggeJS]

B 君的性格，有点不合群，往往语出惊人，他经常推翻百度不正确的观点，别人只把 B 当笑坏来看，
他有自己的立场，稍后公布答案， B 君不觉得自己做错

[minggeJS]

A 君的性格，比较相信百度，百度说什么就信什么，从来不思考！喜欢跟着一群人取笑别人

[minggeJS]

答案明天详细公布，现在人少

[NemoAlex]

楼主一副高高在上的样子
又想搞个大新闻
都听你的都听你的

[arfaWong]

这不是 minggeJS 之父吗？！？！

[df4VW]

你开心就好，好伐

[Andy1999]

你是 B 这贴完结了

[leizongmin]

明哥开心就好，你说啥就是啥啦

[leizongmin]

搬小板凳坐等明哥公布答案

[vigoss]

你是 B ， B 的效率高， try catch 并不浪费性能，结贴。

[ChiangDi]

这种情况我一般不检查，错了直接抛出异常就好，谁让乱传参数呢，不然这种检查没完没了，不如直接用静态语言了。

[yeyeye]

楼主通篇在说 B 好，至少主观上认同 B ，但是不被群友认可，又来 V2 发帖，有想找回自尊的感觉。

随手看了一下评论都说楼主是 B ，才稍微看了下主题，得出以上结论，所以结贴吧，

[yeyeye]

又看了楼主的发帖纪录…… 唉，楼主太明显了

[ck65]

明哥别在乎别人怎么说。 Mc 石头哥都能去愚公移山演出呢。你们都是哥，你们都很行的。

[viko16]

https://github.com/drduan/minggeJS/issues/201

[lasdf]

万火留

[think2011]

╮(╯_╰)╭

[chemzqm]

前端性能问题 99.99% 跟 js 运行效率无关，真正问题是 Dom 渲染以及等待响应
那些喜欢盲从的人，不是靠跟他讲理就能改变的，已经扎根到他思维模式里了

[FrankFang128]

在页面上谈 JS 性能就是个笑话。
99% 的页面瓶颈在网络上好么。

[chemzqm]

不过话说模块化都好多年了，你们代码竟然还用差不多十年前就有的命名空间的方式，这种代码怎么写都蛋疼。

[imn1]

@FrankFang128
百毒贴吧是 1%

[funCoder]

曾经我用 A ，后来我用 B ，不做过早的优化把时间花这了。

[czheo]

一般来说，写成 B 让别人很难根据 stack trace 来 debug 。

[aprikyblue]

你是 B 君，无可置疑的 minggeJS 之父，你正确，你 NB ，结贴

对 lz 高高在上的自大 不敢认同，以及测试过程我认为不够严谨

对于性能。。。 js 谈什么性能，浏览器实现又不尽一样，更何况与其他性能瓶颈相比更是不值一提
关于 try catch ，不仅是 js ，该哪里用什么特性就哪里用，考虑这点性能搞什么。 OOP ，封装，生来干嘛的？计较这点性能，那不如直接全扔了，拿十年前的 copy 大法，全部写在程序入口点一坨。或者去写汇编、机器码。 A 君那一坨 if 真是。。

[233]

lz 你是听说了那个帖子才来注册的吗? (纯好奇)

[andrewpsy]

看了不少结尾把观众往死里惊讶的电影，我大胆猜测一下：你不是 B 却要装 B ，你其实是 C 。

[msg7086]

回到主题吧。简单说几句，以避免很多帖子误导了新人。

对于用异常还是逻辑控制，一般的准则是不要用异常去代替逻辑。
像 OP 这种情况，单独拿出两个函数来，却不说清楚调用上下文的情况下，是没法说明哪种写法更好的。

* 假如这个函数的输入来自一个不确定的源（比如用户输入），那么过滤非法输入属于正常需求，因此属于逻辑代码，应当主动检验数据（即使用 if() ）。

* 假如这个函数的输入来自一个可信源（比如可信的数据库、本地配置文件、第三方可信 API 等），那么函数期望输入总是正确的，因而不正确的输入就属于异常现象，这种情况下应当用异常捕获机制（即使用第二种方法， try catch 并打 log ）。

至于效率，在一个不需要考虑效率的地方并没有什么意义。
如果需要非常高的计算效率（比如支持特别古老的电脑），那就老老实实在服务器端渲染，别用重 js 了。

[XadillaX]

怎么哪都有你_(:з」∠)_

[zhujinliang]

JSON.parse 只能 try … catch 啊摔，情何以堪

[daysv]

我还是选择狗带

[pljhonglu]

哪个方便就用哪个呗~😂

[raopeize]

老实说我从来没用过 IF 语句，正因为我反感 IF 语句。 为什么我反感，因为我完全有开发 IF 语句的能力， IF 语句的底层我都了如指掌。
虽说我反感 IF 语句，但是 IF 语句却占有大量的用户份额，之后我有个想法，不如重新开发一个属于自己思想，自己架构的 IF 语句。
我给了他一个霸气的名字： MingGeIF 语句，
它的名字叫 MingGeIF 语句， MingGe 就是我的大名， 一看到 IF 语句名字，就知道作者是我，知道它是国产的，让别人知道国产 IF 语句一样做得很出色，出众！
我是 mingge 请支持国产 minggeIF 语句，因为我们都是中国人。

[bk201]

用 try 代替 if ？这种代码写起来不累吗？而且可读性太差了吧。 2 种用在不同场合，凤姐你叼

[CodingPuppy]


[deadEgg]

try catch 里面去写逻辑
难怪老有人提出去除 try catch

[cdxem713]

@CodingPuppy 就冲这个，楼主你赶紧去死吧

[yhylord]

@msg7086 这种准则是适用于所有语言吗，还是只是 JS ？因为我看到 Python 似乎推荐用异常代替 if ，如果可能的话。

[overtrue]

楼主肯定是 B ！！！绝对的！

[lanbing]

我发现和我一样聪明的人真多，上面评论的都是。

[SourceMan]

看来 V 友还不太认识明哥
我也支持 B

[iyangyuan]

抛开别的不说，程序怎么可能没有异常处理，谁能保证输入一定是正确的？拿本例来说，如果我重新定义了 toString 方法，不就直接保错了么？再说 A 的可读性很强吗？我怎么觉得还不如 B 容易维护？还有，真想不明白为什么在这种地方追求性能。

[justjavac]

[jarlyyn]

这个做法必须是 A 。

准确的说，是 A 和 b 结合。

IF 判断是已知可处理的错误。

try 是未知错误。应该记录日志并报错。

[freaks]

忍俊不禁

[xiaoxuz]

明哥带了个眼罩?

[Sivan]

我想知道明哥今年多大？

[napsterwu]

https://github.com/drduan/minggeJS
我也就发出来大家看看

[qhxin]

又想搞个大新闻

[int64ago]

我真的很想爆粗口，但是 V 站貌似不允许

但是你把 GitHub 玩坏后准备把 V2EX 也玩坏吗？！

[saber000]

看过一篇文章说 B 的在普通场景下效率高,因为有利于 cpu 分支预测.

[cheny95]

老实说我从来没用过 Windows ，正因为我反感 Windows 。
为什么我反感，因为我完全有开发 Windows 的能力， Windows 的底层我都了如指掌。
虽说我反感 Windows ，但是 Windows 却在测试界占有大量的用户份额，
之后我有个想法，不如重新开发一个属于自己思想，自己架构的 Windows 。
我给了他一个霸气的名字： MingGeWindows ，
它的名字叫 MingGeWindows ， MingGe 就是我的大名，一看到 Windows 名字，
就知道作者是我，知道它是国产的，让别人知道国产 Windows 一样做得很出色，出众。
我是 MingGe ，请支持国产 minggeWindows ，因为我们都是中国人。

https://github.com/drduan/minggeJS/issues/201

[printempw]

全都是感叹号，你很烦诶。到底多喜欢引人注目啊

[powtop]

我要把你打飞！

[cheny95]

怪我太年轻

[mzer0]

@saber000
@jarlyyn
@SourceMan
@iyangyuan
@will0404
@msg7086
@czheo
@funCoder
@chemzqm

发表一下自己的看法. mingge 其实是正确的. 这个问题在 C++里就有过争论, 也是 C++异常处理的经典案例.

在这个特定的场景之下, 其实 mingge 非常聪明, 因为 obj.wo.ok.arr.push("帅哥"); 这一条语句是一个 push 操作, 如果这一条语句出错, 被 catch 到, 那几乎只有一种可能:

* 某一个对象指向 NULL

如果是这样的话, 程序会抛出一个空指针异常, 在优化良好的情形下, 空指针异常的处理速度极快 / 如果异常处理程序被重定向, 那么记录错误日志也效果也极好. 我举一个例子, 下面有一个链表:

* a1->a2->a3->a4 ... ->aN

如果传入的对象是 a1, 但需要调用的对象是 aN, 如何判断 aN 是一个合法对象? 有两种方法.

1) if(a1 && a1->a2 && a1->a2->a3 ... && ... ) 需要进行 N 次判断
2) try { a1->...->aN } catch()

很明显 2)的做法效率极高......

这个情形是很特定的, 因为抛出的异常刚好是一个 NULL 指针异常.

[railgun]

楼主假装他是 B

[mzer0]

虽然我不赞同 mingge 的为人处世, 但这时候要就事论事. 这个例子里 mingge 确实是对的......

[xiamx]

楼主你开心就好...

[Tankpt]

膜拜楼主

[jarlyyn]

@mzer0

try catch 然后 return 个 false 你告诉我这是一样的？

if 判断代表的是处理已知的错误， catch 所有错误然后 return false 是什么鬼？有未知错误你的程序还能跑下去你准备以后怎么 debug?

效率？除了开发效率以外的效率有什么意义？

好吧，我服了。

[mzer0]

@jarlyyn 你是傻逼吗? 你不要因为自己无知, 就觉得有喷别人的资本. 这种 try-catch 的用法是经典用法, 很多书里都有写, 你自己搜一搜资料就知道了. 这种异常属于 NULL 指针异常, 属于可回溯的常见异常, 有很多相关的 debug 技巧, 都很常见.

[neo2015]

当 foo 传入错误参数时 程序是肯定是报错的！ obj.wo 无法索引到时，也同样是报错的

如果是参数错误，那不应用 A 的做法吗？

感觉这个例子就像 输入密码， A 君用 if 判断密码错误呢， B 君是用 try 捕获密码错误

[mzer0]

@jarlyyn 在讨论这个问题之前, 麻烦你看清楚自己有几斤几两, 配不配讨论这个问题! 如果仅仅是因为自己的开发经验没有对方足, 而看不懂对方使用的一些技巧, 然后喷别人, 那你根本没有在这里讨论的资格. mingge 使用了一个中级技巧, 也就是 NULL 空指针异常的技巧, 非常非常非常多的书里都有记载, 五年以上开发者都会知道.

[jarlyyn]

@mzer0

写代码这么多年了，什么坑没踩过，还需要你来教？还需要搜资料？

一定是 Null 指针异常?类型不一致怎么算？甚至内存不足怎么算？

哪本书里教过你 catch 所有错误 return 个 false 的？

除了会人身攻击还会什么？

[tommyzhang]

这个臭傻逼也来 v 站了 ？ 赶紧 block

[jarlyyn]

@mzer0

才 5 年开发经验？

就来 JJYY 了？

写过 JS 么？知道 A 做的是什么么？

[mzer0]

@jarlyyn 我不想和你讨论这个问题. 没见过这个技巧你就说没见过, 你说这么多有什么意义? 你问我, 内存不足怎么算, 类型不一致怎么算, 你自己查一下不就知道了? 这是一个技巧, 三言两语说不清, 你不知道就说不知道, 你查一下吧.

[mzer0]

@jarlyyn 麻烦你查一下 https://stackoverflow.com/questions/651619/what-is-the-advantage-of-using-try-catch-versus-if-else

[jarlyyn]

@mzer0

我需要查？ js 好歹我也写了 10 多年了吧，当年还是不是为了做前端而是为了挂 mud 呢。

你写过 JS 么？还技巧。正常写过点 js 的不知道Ａ在干什么？正常点写过 js 的没专门写过几个函数来实现 A 的那串 if?

还查一下，该报错的地方不报错强行 return false,你到底写过多久代码？

[jarlyyn]

@mzer0

你这个链接有任何价值？

ＳＯ的帖子都拿出来做证据哦？你丢个手册页出来还靠谱点。

回到这个问题

写过 js 或者是脚本语言的代码么？知道 A 在干嘛么？

[dqh3000]

个人角度来看， try catch 没什么不好

说远点，如果有一天 es7 stage3 await 普及， try catch 只能大规模应用

[mzer0]

@jarlyyn 这是一种技巧, 我只是告诉你有这种技巧的存在, 但是我不想和你争论这种技巧有没有存在的必要.

> I'd use the try/catch block when the normal path through the code should proceed without error unless there are truly some exceptional conditions -- like the server being down, your credentials being expired or incorrect. I wouldn't necessarily use it to handle non-exceptional errors -- say like the current user not being in the correct role. That is, when you can reasonably expect and handle an error that is not an exceptional condition, I think you should do your checks.

In the case that you've described -- setting up and performing a query, a try/catch block is an excellent way to handle it as you normally expect the query to succeed. On the other hand, you'll probably want to check that the contents of result are what you expect with control flow logic rather than just attempting to use data that may not be valid for your purpose.

One thing that you want to look out for is sloppy use of try/catch. Try/catch shouldn't be used to protect yourself from bad programming -- the "I don't know what will happen if I do this so I'm going to wrap it in a try/catch and hope for the best" kind of programming. Typically you'll want to restrict the kinds of exceptions you catch to those that are not related to the code itself (server down, bad credentials, etc.) so that you can find and fix errors that are code related (null pointers, etc.).

> In general, try-catch blocks are great because they will break (move to the catch statement) whenever the exception occurs. If-else blocks rely on you predicting when the error will happen.

Edit: Also, catch blocks won't stop your code from halting when an error is hit.

> That ’ s exactly the advantage, using one try/catch instead of multiple if statements. You will also be able to catch any unanticipated errors.

[jarlyyn]

@mzer0

技巧值钱么？

好笑。

拼音写变量名还算技巧呢。

更何况， try catch 所有错误然后 return false 和你给的代码有什么关系？

最后，既然你引入了写了几年代码这个问题，请告诉我你写了几年代码。

[jarlyyn]

@dqh3000

catch 所有错误然后直接 return false 也没什么不好么？

[Tink]

我也用 B

[jarlyyn]

所有觉得用 B 没问题的回答我一个问题

如果传入的 foo 是有 getter 函数的类，然后 getter 函数出错了怎么办？

比如

var foo=function(){
Object.defineProperty(this,'wo',{get:function(){return realWOValue(this);}});
};

[jarlyyn]

@mzer0

再提醒某人回答我做了多久开发的问题。

[cfans1993]

mingge 让我想起 csdn 的一位铜币专家 赵四老师

[jy02201949]

我最喜欢看撕逼了，虽然我从来没用过 js

[shuson]

除了性能原因：
1 ， 一般使用 javascript 多少会涉及异步操作，但是 try-catch 破坏了异步思想，按照 nodejs 社区推荐方案，把 error 交给 callback 来做吧
2 ， javascript 实现过程中，有很多 error 被忽略了，例如把 string “ 2.3abc ” 转换为 Number 的时候，就不会抛出 expection

[wawehi]

程序员特别喜欢纠结对与错， yes or no, true or false, 在这里面纠结，而忘记了目标，项目赚不赚钱才最重要啊……

[jugelizi]

无聊
来个翻页吧

[leeyuzhe]

明哥突然让另外两个人撕逼起来了 @jarlyyn @mzer0
二位真不是明哥的小号？

[codepark]

本君从来不百度~

[ilotuo]

是不是就像 cpp 的 likely.
if 这样逐个比较的方法是应该比较耗性能.

[JimmyCai]

撕的好激烈

[jarlyyn]

@ilotuo

强类型和弱类型的语言有个本质区别。

你不知道调用函数时传进来的参数是什么，参数的方法执行的是什么，参数的属性是一个变量还是调用函数返回的指。

你不可能预期你能遇到的错误，所以只应该判断你能控制的部分。

就以这个代码为例。

可能的错误有类型错误，就是 IF 判断的那一堆。

还可能是类初始化函数错误，还有可能是 Obj.wo 并不是一个变量，而是一个未知的 getter 函数，再函数的调用中有其他位置错误‘’。

[msg7086]

@yhylord 基本是通用的准则。
python 有点不同，因为他家提倡单种方法论，所以就变成只用异常了…

[mko0okmko0]

上面各位都好激烈,我说说我的:
JS 因为从 10 多年前我接触到 5 年前工作常用,只能说坑死人不偿命.
所以我尽可能的将 JS 的内容都包成功能或流程 function xx(){
/*此函数意义与行为描述*/
var re='';
try{
...
}catch(exp){
console.log('xx 有坑:'.concat(exp.message))
re='';// or 0 or -1 看接收方需求更改,尽量不要 null
}
return re;
}

我个人的重点是尽可能在开发期间试出哪里的 function 挂了,然后尽可能的设计不要挂,或是挂了的替代 function 来操作后续.
因为我对 JS 不那么熟也没 9 成以上的把握.
我甚至不知道 JS 的异步是怎除错的,所以我还用全局变数当锁来减少异步问题.
看我的回答就知道 JS 我很浅,所以都是用笨方法.
先求稳定并且自己看得懂,再求性能或语法多猛.
我自己不能理解别人的高大上语法,所以不知道输入那些东西别人的语法会挂,就都包 try

[xujif]

看到 catch 后 return false 就醉了。

[xujif]

B 的 try catch 是很好的，但是 return false 就醉了。 要不 no catch ，要不包装下抛出来

[minggeJS]

关于 try 效率问题的解答： https://github.com/drduan/minggeJS/issues/201

我是 B 君，该事件真人真事，而且是前两天的事，这里应该很多该群的人！老雷就是群员之一，不过当时他不在场，当是我受到侮辱而退群，给我感觉这个群的人技术，人品极度差。当遇到与你意见不合，他们并没有和你讲道理，而是采用侮辱性攻击！老子当时直接把 A 君全家问候完就退群了。我是民主，讲道理之人，当你不讲道理，侮辱我时，我也不会跟你客气。

我是 minggejS 作者！关于 try 对楼上各位作一个回复：

先回复 @msg7086
你好大口气，说误导新人， 我的观点是无论可信源也好，不可信源也好，都应该尽可能地使用 try 回错，因为效率快，代量码少

先不考虑效率， if 语句又长又花费时间，一不心写少一个判断，后果可想然之
那是不是代表 try 能在任何情况下都能完全代替 if ？不是的，人是活的，程序是死的，编程考验我们的正是随机应变能力。

[minggeJS]

@xujif return false 完全没有问题。或者不写也没有问题，上面只是代码测试效果，鸡蛋挑骨完全没意思

[aisk]

给明哥洗地的同学们又该尴尬了。

[minggeJS]

@jarlyyn 你可能比较支持 A 的观点！那么告诉你，你十年的 JS 白学了,
try 能给你挑出骨头来，就算使用 if 语句，我一样挑到你骨头出来。你这样见缝插针的行为否定 try ，不是一个程序员所为
if 有 if 的好处， try 有 try 的好处，作为一名优秀程序员的并不是叫你盲目的使用函数，人是活的，程序是死，人可以随机应该变。 就上述 A 君和 B 君的代码来看， B 君的代码完全合情合理！

[jarlyyn]

@minggeJS

没问题？这是最大的问题好不。

try catch 和 if 对于非异步的异常处理没什么本质差距。

但是 catch 所有错有又不抛就是大问题了。

该执行不下去的就不该执行下去，乱 return 什么鬼？

[jarlyyn]

@minggeJS

合理？

请解释 78 楼的问题。谢谢。

[XadillaX]

我来翻页吧。