引发异常的方法的命名约定（C ++）？

Question

我们正在研究中型到大型C ++代码库，并且正在对其进行重构以使其形状更好。

最近建议我们扩展（可能）引发异常的函数的命名约定，以便一目了然地确定函数是否可能throw异常（通过调用函数直接或间接地） throw）。

虽然我发现可以更轻松地获取信息的能力很整洁，但是我无法撼动这种感觉可能会导致麻烦的感觉，因为没有工具辅助的方法来验证和执行该约定-因此，您不能真正依靠约定（超出提示范围）。

由于对此感到不知所措，我决定从这里寻求建议：
因此，使用这样的命名约定是一个好主意/值得付出努力，并且为此建立了约定吗？

Answer 1

它真的不会决定任何事情。这将是在编程阶段无法执行的另一种特殊约定：如果某人重构了函数却忘记了更改其名称，会发生什么？

如果某人因某个函数的异常发生变化而不得不更改该函数名，那么由于重载解析，您可能会在程序中引入重大更改：弄乱函数名可能会产生意想不到的副作用。

在C ++ 11中，您可以使用noexcept说明符。

Answer 2

原则上，有一个命名约定是一个好主意，但是在实践中应用确实是一个痛苦。我在两个巨大的代码库中的经验告诉您，您仅在新设计中才开始应用此类约定（如果约定不早于此）。

我们遵循的经验法则（对于所有功能，包括那些不抛出的功能）是在方法名称中反映组件名称（它的一部分）和功能（它所服务的），然后在代码名中反映信息性的文本。异常消息。

抛出的异常包含一条消息，如果该软件直接与最终用户交互，则该消息试图反映业务/使用情况；或者，如果消息位于日志内部，则显示一条更具技术性的消息。命名约定没有万能的，而且主要由域驱动。

这完全取决于软件部门在公司中的成熟程度和领域。

Answer 3

可以从C＃中采用。 例如，对于字典，您具有Add和TryAdd。

在我的示例中，我提供一个dll并导出一个必须命名为Start的函数。 另外，由于它是dll导出，因此不应抛出。

但是现在我想在测试中包含此功能。在这里，我实际上是希望它抛出，以便可以在测试报告上看到堆栈。

现在，尽管有所有参数，但函数名称应具有参考性。在这里，我使用StartUnsafe。