所以我的任务是获取时钟时间的输入。用3方法 我们假设该方法内部的gethour,getmin,getsec会检查该值是否在0到60之间(如果没有抛出异常)。 我的问题是: 尝试在主体内部捕获还是更好?还是应该在方法内部进行捕获?
我这样做是因为方法,因为我觉得它更好(只是我的想法),我的教授从中扣除了分数,并指出这样做更好。所以我只想知道哪个更好,为什么。
答案 0 :(得分:3)
无论何时捕获异常,都应该以最合理的级别捕获该异常。
如果无法处理,则应使其沿堆栈向上传播。如果可以合理的方式处理它,则应抓住它并采取适当的措施纠正故障。
这就是全部。每当您编写catch语句时,您都应该问自己:“实际上,在代码中,我现在可以做些什么来解决此问题?”
例如,如果您希望找到一个配置文件而丢失,那么可能的适当措施是退回一些合理的默认配置值。
如果没有您的代码或错误内容的任何上下文,或者您的调用堆栈的什么级别在做什么,那么我们不能告诉您更多。
答案 1 :(得分:1)
如果您的方法应该定义抛出异常,则它不需要捕获任何异常,因为应该将其定义为抛出异常并实际上抛出异常
答案 2 :(得分:0)
在异常处理中的实践是,您应将异常壁橱捕获到发生异常的位置。它使回溯更容易,同时也使流量控制更好。 Try-catch主要用于防止程序在非常特殊的情况下崩溃,同时向用户显示用户友好的错误消息并在其他地方记录完整的错误。
但是,如果您已经以一种特定于任务的方式正确地处理了异常,则可以将更通用的try-catch方法用作故障情况下在测试期间未捕获的错误的故障保护,或者发生非常罕见的事情。
答案 3 :(得分:0)
一个好的做法是仅在您可以对它采取一些有意义的操作时才处理异常。我没有完整的示例,但是我想如果您在方法内部捕获到异常,则需要向调用方返回一些值。然后,调用者将如何知道您的方法中是否包含无效数据(超出0..60范围)? 另一方面,如果您抛出一个异常并在main()中处理它,则您将有更多选择来执行此操作,并且该方法不会隐藏错误情况。 这也称为关注点分离。方法功能和错误处理是分开考虑的,不应混为一谈。如果您在main()中处理异常,那么您将拥有更好的SoC:方法中的功能,main()中的错误处理
答案 4 :(得分:0)
实际上,将try-catch块放在哪里都没有关系。如果您不想在方法内部捕获异常并返回到调用方方法(即main()),则可以在那里进行处理。它完全取决于需求。我不确定你的教授为什么这样做。你可以问他。