0

このトピックについて検索しましたが、実際に関連する回答が見つかりませんでした...

次のように宣言された抽象クラスがあるとします。

class Abstract{

    virtual Interface* createHandle() = 0;

    virtual ~Abstract() = 0;
};

基本的に、クラス インターフェイスの任意の実装を返す一意の関数を提供する抽象クラス (抽象クラスでもあります)。

このような設計でエラーをどのように処理できるのだろうか。createHandle()エラーが発生し、インターフェイスの実装へのポインタを返すことができない場合、これを適切に処理して通知するための最良の方法は何ですか?

最初に頭に浮かんだのは、null ポインターを返し、返されたポインターが null かどうか呼び出し元のコードをチェックインすることでした。それは機能しますが、インターフェイス（つまりAbstract）は、createHandle（）がnullポインターを返すことができること、またはnullポインターを返してエラーを通知することを決して意味しないため、これは非常に設計が不十分であることがわかります（そして、 「エラーの場合はnullを返す必要があります」というコメントを残すだけです）。

次に、この情報を Interface ポインターで運ぶことを考えました。つまり、ある種のエラー コードを設定/取得する 2 つの公開非仮想関数をクラスに追加します。しかし、Interfaceクラスとは何の関係もないので、まったく好きではありませんが、createHandle()Interfaceが知識を持っていない実装です（つまり、このクラスを使用するコードに関連するエラーを格納するメンバー変数を持っていると感じます）私は間違っているかもしれませんが、私の意見では非常に間違っています）。

それでは、エラーが発生した場合にこの関数がどのように動作するかを指定するエレガントな方法は何でしょうか(実装とは完全に独立した方法で、実際にはまったく逆です:実装にこれまでの方法でエラーを処理するように強制します)指定）。

4

3 に答える 3

3

ケースが例外的であり、処理する必要がある場合はスローできexceptionます (ただし、これを強制することはできませんが、少なくとも状況を例外的にマークします)。それ以外の場合は、返品nullptrはまったく問題ありません。

たとえば、潜在的に存在しない可能性のあるファイルを読みたい場合、それはプログラムエラーではなく、予期される状況であるためnullptr、たとえば FileReader を返すことは理にかなっています。

また、それnullptrが有効な考えであることを示し、チェックを強制するためにboost::Optional、エラー コードを含む可能性のある独自のオプション クラスを返すこともできます。

于 2013-05-14T13:57:18.797 に答える
1

例外をスローするか nullptr を返すかを選択できますが、両方を同時に選択することはできません。

null はサイレントですが、呼び出し元に問題の正確な理由を伝えるため、例外をスローすることをお勧めします。

于 2013-05-14T14:05:10.003 に答える