为什么使用 'try' ' catch' 'finally' 来处理异常-解网

问：

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

但这里有一个悖论。

如果我没有意识到程序的这一部分可能有例外。我也不会使用 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 帮助您将泄漏的水倒回桶中

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

如果您没有注意到铲斗正在泄漏

尝试捕捉也没有多大帮助

这是我的困惑

异常 try-catch

在所示的特定情况下，在尝试使用输入之前验证输入对我来说确实更有意义。如果输入无效，根据函数的需要，我要么返回默认响应，要么（更有可能）抛出异常。使用代码可能想要处理该异常，但这实际上取决于该代码。但你到底在问什么？

0赞 Rogue 7/31/2023

例外实际上是你的朋友，它们有两种类型：选中和未选中。未经检查的（即运行时）异常通常是编程错误的结果，通常最好不捕获这些异常，除非顶级处理程序（例如命令调度程序）捕获这些异常，以便注意到并解决编程错误。选中的异常表示程序无法控制的故障情况（例如 IO、OS 信号、错误输入），允许您在出现这些情况时做出反应。这些往往在离错误产生的站点更近的地方处理。

答：

0赞 Dmytro Titov 7/31/2023 #1

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

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

但是，如果将逻辑包装在一个块中，则可以从错误中恢复（当然，并非总是如此 - 取决于错误）。try-catch

那么你可能会问：“为什么不把整个程序包装在一个超级块中”？嗯，你可以。但问题是，大多数时候“恢复”取决于两件事：try-catch

发生了什么类型的错误？
它究竟发生在哪里？

根据答案，您将尝试以一种或另一种方式恢复应用程序流，如果您只是对整个应用程序进行最终包装，这将是有问题的 - 如果不是不可能的话。try-catch

您的后续问题可能是：“但是，我如何决定我的 es 的粒度”？我的代码库中应该有多少个？我应该多久插入一次？我应该把每一行都换成自己的吗？或者每个函数/方法都可以吗？try-catchtry-catch

嗯，这些都是好问题，因为这里没有灵丹妙药。这实际上取决于您的代码和您使用的特定编程语言。例如，一些 PL（如 Java）有所谓的“检查异常”：如果某个函数定义了一个检查异常，那么你必须在调用这个函数时（或者稍后，在调用堆栈的某个时间点）捕获它。有些语言没有这个概念。此外，请记住不同的范式：过程编程、函数式编程、OOP 等。所有这些都会影响您处理异常的策略。根据经验，您可以遵循一个建议，即每当您打开某些资源（文件、数据库连接等）时，将其包装起来并确保在块中关闭此资源。有些语言（如 Java）甚至有一种特殊的语法，称为 try-with-resources。try-catch-finallyfinally

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

Why use 'try' ' catch' 'finally' to handle exception

评论

评论