Question

我道歉，无法提出更好的问题标题，请听我说。

我写了一个视图，我在创建实例后发送电子邮件，它按预期工作（ba dum tss）

def my_view(request):
# some code
# notify_by_email code
# some more code

现在我正在考虑将notify_by_email提取到单独的方法notify_by_email(new_instance)。我正在考虑这样做有几个原因：a）notify_by_email部分代码使view混乱并降低了可读性b）我感觉我可能在另一个视图中使用该方法，会违反DRY。

无论如何，现在我在这里

def my_view(request):
# some code
notify_by_email(new_instance)
# some more code

现在我正在考虑错误处理，如果无法发送电子邮件（或其他任何方法，我不想让整个视图掉落） - 我对这个概念感到好奇。现在我们需要try-block，对吗？

我应该在视图中try-block：

def my_view(request):
# some code
try:
  notify_by_email(new_instance)
except SomeException:
  pass
# some more code

或者无论如何调用方法，并在方法本身内进行错误处理？

我不知道这个问题是Python ic还是Django是...我的逻辑中是否存在缺陷？这些方法之间是否存在概念上的差异（正确/错误的方式）？请解释一下。

谢谢。

Answer 1

常见的说法是提前抛出异常并及时捕获异常。这句话的前一部分很简单，但后一部分不是。

如果您尽可能晚地抛出异常，那么所有异常处理都将在最顶层进行。那会很难看。相反，我提出了更多的内容：

处理得足够晚，因为异常处理方法的使用不会变得专门化。（例如，您在两个位置使用notify_by_email，其中一个您不关心处理异常，因此您只需直接在方法中处理它并跳过异常;然后在其他地方您想要异常，但是您由于您在方法中的异常处理，无法使用它。）
处理得足够晚，你有足够的范围来充分处理你的异常。如果您需要向用户警告电子邮件失败的GUI程序，并且您的功能无法访问绘制警报所需的功能，则需要提高范围。
不要等待更长时间。一旦你处理得足够高，你没有专门的功能，并且你有足够的范围，这是一个很好的地方。
代码结构很像艺术。这是主观的，当你觉得它是一种改进时，你有时会违反规则。

如果您有一个方法send_email(address, contents)，并且其范围内的所有内容都是发送电子邮件所需的属性，那么处理该异常除非您只想继续前进，否则不会非常有用问题。如果你想在你的程序界面上显示一条消息，你需要访问显示这样的功能，这是你没有的。

现在，我不熟悉Django，所以我不知道view在这种情况下是什么，但听起来它与显示事物有关。如果是这种情况，那么my_view将足够高以正确处理异常。现在，如果您的notify_by_email方法显示一条消息说它已成功，那么这将是处理异常并显示错误的合适位置，因为这意味着它具有必要的范围。

如果异常不是一个大问题，并且您只想继续，那么您决定编写一个日志文件，那么您就在现场处理它。这是否意味着正确地编写文件，或者将消息附加到带有其他可能消息的变量并稍后写入。

对于更深入的输入和讨论，还有这篇文章here

概念。从视图中调用方法。错误处理

1 个答案: