在使用C++开发应用程序的时候, 很多程序员非常钟情于使用try...catch... 的异常捕获机制. 这使得程序的错误被悄然无声的掩盖了, 对于用户而言, 无论程序内部发生了什么样的问题,而表相上却像无事一样风平浪静.
使用try...catch结构, 有时是一种逃避责任的方法.无论这段代码隐含着什么样的隐患, 只需要用try...catch包裹起来,无论发生了什么错误, 都不会让程序崩掉,顶多弹出些提示的对话框或则重新将出现错误的线程重新起动.
如果我们使用的第三方软件包本身要求try...catch机制,那么因此而使用try...catch是无可厚非的. 但如果在程序设计时过分的去依赖try...catch,这无疑是程序设计上的败笔. 因为使用try...catch, 可能使你在调试时,可能无法准确的去定位错误的位置.这在调试程序时会增加调试的难度. 同时, 过多的使用try...catch,也使得程序的二进制代码的效率降低.
所以, 我认为在程序设计中, 在必要的时候可以使用try...catch, 但不能过分的去依赖它, 把他当成偷懒的工具. 要更多的去利用返回值和细分模块来降低程序出错的机率.
使用try...catch结构, 有时是一种逃避责任的方法.无论这段代码隐含着什么样的隐患, 只需要用try...catch包裹起来,无论发生了什么错误, 都不会让程序崩掉,顶多弹出些提示的对话框或则重新将出现错误的线程重新起动.
如果我们使用的第三方软件包本身要求try...catch机制,那么因此而使用try...catch是无可厚非的. 但如果在程序设计时过分的去依赖try...catch,这无疑是程序设计上的败笔. 因为使用try...catch, 可能使你在调试时,可能无法准确的去定位错误的位置.这在调试程序时会增加调试的难度. 同时, 过多的使用try...catch,也使得程序的二进制代码的效率降低.
所以, 我认为在程序设计中, 在必要的时候可以使用try...catch, 但不能过分的去依赖它, 把他当成偷懒的工具. 要更多的去利用返回值和细分模块来降低程序出错的机率.