异常处理问题

Mr_Archer 2021-03-24 03:33:05
求问下,在进行异常处理的时候,如果是连续进行外部接口的调用,没有逻辑判断,在进行try-catch的时候,每一次调用都进行独立的try-catch好还是一段调用用一个try-catch好一点
...全文
423 9 打赏 收藏 举报
写回复
9 条回复
切换为时间正序
请发表友善的回复…
发表回复
程序设计师的职责首先是调试、测试程序,只是偶尔才发布一次。 在调试时,你应该尽量删除 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版本代码。
  • 打赏
  • 举报
回复
卷卷不运动 2021-03-31
如果只是为了判断外部接口是否报错 肯定多个try catch 定位到哪个接口报错
  • 打赏
  • 举报
回复
白衣如花 2021-03-26
感觉应该充分信任外部接口,只对返回结果进行判断,比如返回null返回0

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

做一个全局catch打印调用栈就行
  • 打赏
  • 举报
回复
兔子-顾问 2021-03-26
异常捕获机制需要额外资源和影响效率,尽可能只对无法预判的代码加异常处理。
  • 打赏
  • 举报
回复
正怒月神 2021-03-26
如果你有针对多个接口,有自定义异常, 那么你可能适合 多个 try catch; 反之,全局统一捕获异常,然后在返回一个异常的结果就好了。 这甚至连try catch 可能都不需要。
  • 打赏
  • 举报
回复
jhonsonzhang 2021-03-26
每次调用都用独立的。用一个的话,你的catch段不好写。具体哪个调用的问题,如何处理,弄得很麻烦。
  • 打赏
  • 举报
回复
morliz子轩 2021-03-26
引用 楼主 Mr_Archer 的回复:
求问下,在进行异常处理的时候,如果是连续进行外部接口的调用,没有逻辑判断,在进行try-catch的时候,每一次调用都进行独立的try-catch好还是一段调用用一个try-catch好一点
接口调用,适用于先提前抛出,再进行全局调用异常。每调用一次接口,都try catch是不高效的。
  • 打赏
  • 举报
回复
石岩Maple 2021-03-25
看要求,一般一个try-catch就行,因为外部接口如果出现异常,如果外部接口能够主动告知异常,你这边只要在你自己内部定义好和外部接口一致的接收逻辑就行了,如果是你自己内部调用外部接口出的问题,比如说外部接口连接不上,这时候程序会直接出异常,如果出了异常后你还要执行其他逻辑,那么在请求外部接口的代码段try-catch就行了,如果请求接口后就终止执行任何其他逻辑,那么就整个代码段try-catch就行啦
  • 打赏
  • 举报
回复
一品梅 2021-03-25
调用和被调用的关系,一个抛出异常,一个对异常进行处理,最终抛出,抛出,再抛出,调用者最终接收到了抛出的异常,try...catch块进行处理。
  • 打赏
  • 举报
回复
相关推荐
发帖
C#

10.8w+

社区成员

.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
帖子事件
创建了帖子
2021-03-24 03:33
社区公告

让您成为最强悍的C#开发者