如何处理失败的方法：
- 使用异常
- 使方法返回bool
第一种方法是当出现问题时抛出异常。但是有问题的代码需要放在try块中，然后你需要写catch块。
第二种方法需要检查方法，然后做点什么。
那么，基本上，这不是相同的机制吗？您有两部分：检测出问题，然后采取措施。那么我用哪种方法重要吗？
例外情况的主要好处是它们是非本地的。您可以在离异常抛出位置几层的调用层之外捕获异常。这样，介于两者之间的代码就不必关心异常(除了确保在展开过程中正确清理，即异常安全)，这使得异常情况不太可能被遗忘。但这种好处是有代价的：堆栈解除比简单地返回一个值更复杂。就性能而言，返回值方法通常更简单。
所以我会用这些来选择：如果出于某种原因，处理问题的唯一合理的地方直接在调用函数的位置，并且如果你相当确定每个调用方在任何情况下都会包含某种错误处理代码，并且不太可能忘记这样做，那么返回值将是最好的。否则，我会破例。
基本上，两种方法都可以达到相同的行为，但Exception可以提供两个附加值：
1) 您不必处理精确调用方法中的错误，它可以位于调用堆栈的任何位置。当您只想传递错误时，这将从代码中删除if(!doSomthing()) return false;。
2) 它允许您在一个try下编写一个代码块，并在一个catch块中处理其下的所有错误。
没有简单的答案。例如，以下是文章C++例外：优点和缺点的结论
对于"；异常或错误代码"；问题需要根据开发团队面临的具体情况做出决定。一些粗略的指导方针可能是：
如果您有一个良好的开发过程和实际遵循的代码标准，如果您正在编写依赖RAII为您清理资源的现代风格C++代码，如果您的代码库是模块化的，那么使用异常可能是一个好主意。
如果您使用的代码没有考虑到异常安全，如果您觉得开发团队缺乏纪律，或者如果您正在开发硬实时系统，则可能不应该使用异常。
我的个人规则是，只有在发生异常时，即问题可能根本没有出现时，才引发异常。否则我会使用返回值(大部分时间)。
例如，当搜索MUST存在的文件时，找不到它会引发异常。但是，如果文件可能存在，也可能不存在，找不到它也不是例外，所以不需要例外。
所有情况都没有答案。这两种方法都有优缺点：
例外情况：
- 在本地处理时稍微详细一些
- 如果无法在本地处理错误，则可以简单地忽略
- 可以静态地(在异常类型中)和动态地(在抛出的对象中)携带关于错误的任意多的信息
- 在某个位置需要一个处理程序以避免终止程序
- 可能有更多的运行时开销(但在不抛出任何东西时可能会更少，这取决于它们的实现方式)
- 要求代码是异常安全的
返回值：
- 如果不在本地处理，则必须手动向上传递到堆栈：如果忘记了，很容易出现错误
- 有一个固定的类型，限制了它们可以携带的信息量(尽管您可以返回一个指向多态类型的指针，并处理相关的生存期管理问题)
- 如果函数也需要在成功时返回某些内容，则使用起来很尴尬
有两个主要区别：(a)调用代码更容易忽略布尔状态代码。(b) 例外情况提供了比单纯的false更多的上下文。您可以区分业务逻辑错误、I/O错误和输入验证错误等。
我更喜欢布尔。我认为这是个人偏好。我发现它更容易阅读。