【问题标题】:At what level and how is appropriate to catch exceptions在什么级别以及如何适当地捕获异常
【发布时间】:2012-06-11 09:28:22
【问题描述】:

我知道这是主观的,但应该在最低级别或更高级别捕获异常。 我问是因为我通常这样做

try 
{
 //..
}
catch
{
 //LOG
}

所以当我实现一些“低级”功能时,比如

std::string read_from_file(const std::string& file_name);

我不知道该怎么办:
1) 让调用者处理异常。
2) 捕获(记录?)并重新抛出
3) catch 并改变函数,使 bool 为返回类型(try 的最后一行是 return true;catch 的最后一行是 return false;)。我不喜欢这个,但我已经看过很多次了。
4) ???

【问题讨论】:

  • 视情况而定,但通常(1)让调用者处理异常,或者 Catch、Log、rethrow...

标签: exception-handling


【解决方案1】:

在可以真正处理它的水平或没有其他地方可以扔它的时候抓住它。

捕获和重新抛出不会处理任何事情,除非您的目的是将异常包装在更具说明性的东西中(例如,Spring 持久性通过查看 SQL 错误代码将 SQLException 包装成更有意义的东西)。

有时没有其他地方可去。任何用户都不应该看到堆栈跟踪,因此控制器应该捕获所有内容并重定向到友好的错误页面。

您可以捕获和更改返回类型,但用户会丢失信息。 “真/假”不会告诉他们与堆栈跟踪相同的信息。为捕获的异常发回“成功”对我来说感觉不对。

如果您无法处理异常,请将其冒泡到可以处理的层。如果你能处理它,那就去做吧。

【讨论】:

  • bool 返回类型我的意思是:try 中的最后一行返回 true; catch 中的最后一行是 return false;
  • Catch and rethrow with new name 通常由库完成,可能是为了让库的用户知道错误来自哪个组件。
  • @duffymo:我只想提供一种使用 catch 和 re-throw 的情况,因为这个问题对我来说似乎很笼统。
  • 似乎建议实际上是通用的,但是“处理它”这个词没有很好的定义。 Java 和 .net 的异常处理机制的一个主要弱点是,当概念有些正交时,它们强烈地将“处理异常”与“解决它”联系在一起。例如,如果在尝试从字节数组反序列化对象时发生异常,则放弃部分构造的对象并处理无法反序列化的事实通常足以解决问题,无论原因如何对于原始异常。
  • 不幸的是,没有像样的方法来区分这种行为可以解决问题的情况和不能解决问题的情况。太糟糕了,没有标准属性或异常对象可以用来表示“我还没有解决,所以重新抛出我”的其他方法。
猜你喜欢
  • 1970-01-01
  • 2011-06-05
  • 1970-01-01
  • 2011-09-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-15
相关资源
最近更新 更多