异常处理问题

[Mr_Archer]

求问下，在进行异常处理的时候，如果是连续进行外部接口的调用，没有逻辑判断，在进行try-catch的时候，每一次调用都进行独立的try-catch好还是一段调用用一个try-catch好一点

[一品梅]

调用和被调用的关系，一个抛出异常，一个对异常进行处理，最终抛出，抛出，再抛出，调用者最终接收到了抛出的异常，try...catch块进行处理。

[石岩Maple]

看要求,一般一个try-catch就行，因为外部接口如果出现异常,如果外部接口能够主动告知异常,你这边只要在你自己内部定义好和外部接口一致的接收逻辑就行了，如果是你自己内部调用外部接口出的问题,比如说外部接口连接不上,这时候程序会直接出异常,如果出了异常后你还要执行其他逻辑,那么在请求外部接口的代码段try-catch就行了，如果请求接口后就终止执行任何其他逻辑,那么就整个代码段try-catch就行啦

[morliz子轩]

引用 楼主 Mr_Archer 的回复:

求问下，在进行异常处理的时候，如果是连续进行外部接口的调用，没有逻辑判断，在进行try-catch的时候，每一次调用都进行独立的try-catch好还是一段调用用一个try-catch好一点

接口调用，适用于先提前抛出，再进行全局调用异常。每调用一次接口，都try catch是不高效的。

[jhonsonzhang]

每次调用都用独立的。用一个的话，你的catch段不好写。具体哪个调用的问题，如何处理，弄得很麻烦。

[正怒月神]

如果你有针对多个接口，有自定义异常， 那么你可能适合 多个 try catch; 反之，全局统一捕获异常，然后在返回一个异常的结果就好了。 这甚至连try catch 可能都不需要。

[兔子-顾问]

异常捕获机制需要额外资源和影响效率，尽可能只对无法预判的代码加异常处理。

[白衣如花]

感觉应该充分信任外部接口，只对返回结果进行判断，比如返回null返回0

包括我们写库，也不应该抛出异常，而应该返回异常值

做一个全局catch打印调用栈就行

[卷卷不运动]

如果只是为了判断外部接口是否报错 肯定多个try catch 定位到哪个接口报错

[以专业开发人员为伍]

程序设计师的职责首先是调试、测试程序，只是偶尔才发布一次。 在调试时，你应该尽量删除 try-catch，让异常尽可能在测试和调试时早一点跳出来。此时写 try-catch 的人大致是想要蒙自己的领导和同事，让他们难以发现自己没有进行 if-else 检测各种异常所随后造成的程序重大异常。如果你使用到别人提供的工程经常“带病”还继续运行，而不是抛出异常，你肯定更不信他们。这其实微妙的理念问题，你如不想经常被人欺骗那么你自己也不要经常用 try-catch 欺骗别人。 在调试和测试中习惯使用try-catch来掩盖错误的人，通常都丧失了基本的调试能力。相反不写 try-catch 而是用正常的 if-else 检测程序异常数据的人，不但程序逻辑更清晰，出了问题也往往用几秒钟就意识到是具体哪一行代码的问题。因此遇到一些“自作聪明”的编程爱好者喜爱写 try-catch 代码的时候，我一般直接删除了。 程序发布前，是要给最终用户一个良好的体验。在表现层要给最终用户一个更友好的提示，然后让进程继续运行，而不是终止。因此程序都有 Debug 和 Release 之分。再代码中可以使用“条件编译语句”区分 Debug 和 Release，使得仅仅针对 Release 而在必要的一些代码外边才生成 try-catch 语句。注意这是 Release，而不是用来调试和测试的Debug版本代码。