c ++非致命异常处理

时间:2010-12-13 21:15:29

标签: c++ exception-handling

我在另一个帖子的评论中被告知我应该在任何异常情况发生时使用异常,即使它对脚本不是致命的。这是因为我使用类似于以下的结构:

return err("File could not be loaded");

将错误打印到屏幕,并返回false,终止指令处理。有人建议,除了例外情况,这样做会更好。

麻烦的是,无论出于何种目的,程序都是一个语言解释器,通过控制台控制,这意味着只要命令输入不正确,或者解释代码中存在错误,就需要出错待显示。

除了这些问题似乎很小,无法作为例外处理之外,应该如何实施?如何使用try块来控制处理路径?例如,目前我的代码如下:

if(!validate(code))
  return false; //the validate function already having output the error
else
  process(code);

如果验证(代码)成功,我应该如何确保只执行进程(代码)?我应该只从catch块中的函数return false;开始吗?这似乎回到了使用返回值来处理异常事件的原始问题。在我看来,根本问题在于问题根本不是例外,但我更愿意接受那些比我更有经验的人。

6 个答案:

答案 0 :(得分:4)

如果操作可能 - 通过设计 - 成功或失败,并且这两者都很常见,那么构造命令流可能是最明确的,以便“明确”检查错误,例如布尔值“验证“功能。

如果你不想通过错误检查来打扰你的常规控制流并希望将检查移到其他地方,可能是某些函数调用级别,那么异常会派上用场。

你的情况听起来好像不需要例外。如果您的代码在没有它们的情况下看起来干净,请坚持下去。

答案 1 :(得分:3)

异常的想法是你不需要像单独的“验证”步骤那样的东西。每当“进程”到达某个东西被破坏的点时,抛出异常。

如果由于某种原因确实需要单独的验证步骤,那么它看起来像

validate(code);
process(code);

验证会在失败时抛出异常,在这种情况下永远不会达到进程。

答案 2 :(得分:2)

try
{
  validate(code);
  process(code);
} 
catch(...)
{
  return false;
}
return true;

假设validate抛出,process将不会发生。

答案 3 :(得分:2)

也许你希望你的顶级循环看起来像这样:

while (!quit) {
    try {
        process_command_line_input();
    }
    catch (const std::exception& ex) {
        std::cerr << "Error: " << ex.what() << std::endl;
    }
}

因此,process_command_line_input()获取下一行输入并执行任何操作。如果检测到任何错误,则抛出异常,顶级循环显示它,然后继续下一个输入行。

答案 4 :(得分:1)

问题是您已将功能设置为使用返回代码。当您的代码已经设置了返回值时,您不能只拖放异常。

正确的方法就像

std::string code;
// input into code
try {
    validate(code);
    process(code); // Throws an exception.
}
catch(std::runtime_error& except) {
    std::cout << except.what();
    // recover from here.
}

答案 5 :(得分:0)

没有一个正确的答案 它高度依赖于代码和情况:

在您的情况下,上面的简单代码(如果它是我自己的类)然后错误代码是好的:

class MyClass
{
    public:
        void processesValidCodesOrIgnore(int code)
        {
            if (validate(code))
            {
                processesCode(code);
            }
        }
    private:
        bool validate(int);
        void processesCode(int);
};

由于validate方法是私有的,我知道它的结果将始终被检查而不会被忽略,因此在这种情况下很容易使用错误代码。

另一方面,如果验证是公开的,我肯定会考虑使用例外(取决于使用情况)。因为这会迫使调用者主动检查问题,而不是默默地忽略它们。