接口(抽象类)设计的最佳方法?

时间:2013-05-14 13:54:29

标签: c++ error-handling abstract-class

我搜索过这个主题但却找不到相关的答案......

假设我有一个像这样声明的抽象类:

class Abstract{

    virtual Interface* createHandle() = 0;

    virtual ~Abstract() = 0;
};

基本上,一个抽象类,它提供一个返回类Interface(也是一个抽象类)的任何实现的唯一函数。

我想知道如何用这种设计处理错误。如果createHandle()遇到错误并且无法返回指向Interface实现的指针,那么正确处理和通知它的最佳方法是什么?

我想到的第一件事就是返回一个空指针,然后在返回的指针为空时检入调用代码。它会工作,但我发现这个设计很糟糕,因为接口(即Abstract)从不暗示createHandle()可以返回空指针,或者返回一个空指针来发出错误信号(和我发现只是留下评论“如果错误应该返回null”这一事实我觉得很糟糕。)

然后,我想在接口指针中携带这些信息。也就是说,将两个公共非虚函数添加到设置/获取某种错误代码的类中。但我完全不喜欢它,因为它与Interface类无关,而是与接口不了解的createHandle()的实现(即有一个成员变量存储与代码相关的错误< em>使用这个类,在我看来感觉非常错误,虽然我可能错了)。

我想知道,在错误的情况下指定这个函数将如何表现的优雅方式(在某种程度上完全独立于任何实现,实际上是另一种方式:强制实现处理错误方式已被指定)。

3 个答案:

答案 0 :(得分:3)

如果案件是例外,您可以抛出exception必须处理(虽然您不能强制执行此操作,但至少标记情况例外)。否则返回nullptr是完全可以的。

例如,如果您想要读取可能不存在的文件 - 这不是程序错误,而是预期的情况,因此返回文件读取器的nullptr会导致这种情况。

另外要表明nullptr是有效的思考并强制执行检查,您可能会返回boost::Optional或您自己的可选类,其中也可能包含错误代码。

答案 1 :(得分:2)

如果您启用了例外,则可以选择例外。

答案 2 :(得分:1)

你可以选择eigher throw exception,或者返回nullptr,但不能同时返回两者。

我建议抛出异常,因为它告诉调用者问题的确切原因,而null是静默的。