为什么要用'try''catch''finally'来处理异常

Question

老师说使用异常测试可以提高程序的健壮性。显然这是真的。

但是这里有一个悖论。

如果我没有意识到这部分程序可能有异常。我也不会使用 try{} ！ 如果我意识到这个程序可能有异常，为什么我不修复这个程序以使其更加健壮呢？

例如，简单的功能

function c=div(a,b)
 c=a/b;
end

如果 b=null 或 b=0 或 b 是 char ，就会出现异常，为什么我必须使用

function c=div(a,b)
try{c=a/b;
   }
catch (children class){…………
                   } 
catch(parent class){…………
                }
catch(exception e){…………
               }        
end

我为什么不使用 switch case + @NotEmpty @NotNull isDigit() 来验证输入参数是否正确？

如果您发现水桶漏水

try catch 可以帮助您将漏水倒回桶中

但是我为什么不堵住桶孔呢？

Answer 1

这与您提前知道或不知道您的程序可能会在某些特定代码块中抛出异常无关。这是关于如果发生“某事”时能够恢复的问题。例如，如果错误导致您的应用程序崩溃，则会导致负面后果：

1. 一些打开的资源可能无法正确关闭（取决于操作系统和许多其他因素）。
2. 用户体验很差：人们不喜欢看到他们正在使用的应用程序发生致命崩溃。

但是，如果将逻辑包装在

try-catch

块中，则可以从错误中恢复（当然，并不总是如此 - 取决于错误）。

那么你可能会问：“为什么不把整个程序包装在一个 uber-

try-catch

块中”呢？好吧，你可以。但事实是，大多数时候“恢复”取决于两件事：

1. 发生了什么类型的错误？
2. 具体发生在哪里？

根据答案，您将尝试以一种或另一种方式恢复应用程序流程，如果您只是有一个终极的

try-catch

包装整个应用程序，这将是有问题的 - 如果不是不可能的话。

您的后续问题可能是：“但是，我如何决定我的

try-catch

es 的粒度”？我的代码库中应该有多少个？我应该多久插入一次？我应该将每一行包装成自己的

try-catch

吗？或者每个函数/方法都可以吗？

嗯，这些都是好问题，因为这里没有灵丹妙药。这实际上取决于您的代码以及您正在使用的特定编程语言。例如，某些 PL（如 Java）具有所谓的“检查异常”：如果某个函数定义了检查异常，那么当您调用该函数时（或者稍后，在某个时刻，在调用的上部），您必须捕获它。堆）。有些语言没有这个概念。另外，请记住不同的范例：过程式编程、函数式编程、OOP 等。所有这些都会影响您处理异常的策略。根据经验，您可以遵循以下建议：每当您打开某些资源（文件、数据库连接等）时，请将其包装在 try-catch-finally

 中，并确保在 

finally

 块中关闭该资源。有些语言（如 Java）甚至为此有一种特殊的语法，称为 

try-with-resources。