0

次のような例外クラスがあります。

class ExtensionExceptionType;
class Object;

class Exception
{
public:
    explicit Exception () { }

    Exception(                      const std::string &reason ) { PyErr_SetString( _Exc_RuntimeError(), reason.c_str() ); }
    Exception( PyObject* exception, const std::string &reason ) { PyErr_SetString( exception,           reason.c_str() ); }

    Exception( PyObject* exception, Object& reason );

    Exception( ExtensionExceptionType& exception, const std::string& reason );
    Exception( ExtensionExceptionType& exception, Object&            reason );

    void clear() { PyErr_Clear(); } // clear the error -- technically but not philosophically const

    static Object err_type();
    static Object err_value();
    static Object err_trace();

    static Object err_stats( uint32_t i ); // 0 1 2 for {type, value, trace}

    static void wrap( int condition ) {
        if( condition == -1 )
            throw Exception{};
    }
};

// Abstract
class StandardError     : public Exception      { protected: explicit StandardError()    {} };

class LookupError       : public StandardError  { protected: explicit LookupError()      {} };
class ArithmeticError   : public StandardError  { protected: explicit ArithmeticError()  {} };
class EnvironmentError  : public StandardError  { protected: explicit EnvironmentError() {} };

// Concrete (π)

// e.g.
//    class TypeError: public StandardError
//    {
//    public:
//        TypeError (const std::string& reason)
//        : StandardError()
//        {
//            PyErr_SetString( Py::_Exc_TypeError(),reason.c_str() );
//        }
//    };

#define CONCRETE( CLASS, BASE ) \
class CLASS: public BASE \
    { \
    public: \
        CLASS (const std::string& reason) \
        { \
            std::cout << "(Exception.hxx) " #CLASS " from PyCXX (" << reason.c_str() << ") \n"; \
            PyErr_SetString( _Exc_##CLASS(), reason.c_str() ); \
        } \
    };

// it appears that these classes are only for manually RAISING Python errors
// i.e. Raising an exception in the Python runtime
// because if I type something in to the Python console, I can make (e.g.) a KeyError occur, but these classes don't get hit.

CONCRETE( TypeError,            StandardError   )
CONCRETE( IndexError,           LookupError     )
CONCRETE( AttributeError,       StandardError   )
CONCRETE( NameError,            StandardError   )
CONCRETE( RuntimeError,         StandardError   )
CONCRETE( NotImplementedError,  StandardError   )
CONCRETE( SystemError,          StandardError   )
CONCRETE( KeyError,             LookupError     )
CONCRETE( ValueError,           StandardError   )
CONCRETE( OverflowError,        ArithmeticError )
CONCRETE( ZeroDivisionError,    ArithmeticError )
CONCRETE( FloatingPointError,   ArithmeticError )
CONCRETE( MemoryError,          StandardError   )
CONCRETE( SystemExit,           StandardError   )

私はちょうど追加しました：

    static void wrap( int condition ) {
        if( condition == -1 )
            throw Exception{};
    }

...他にもいろいろあったので...

if( SomePythonFunc(...) == -1 ) throw Exception{};

...次のように整理されています。

Exception.wrap( SomePythonFunc(...) ); // much nicer, I think

ただし、次の場合もあります。

if( SomePythonFunc(...) == -1 ) throw TypeError{ "foo" };

...そして、同等のラッピングを実行する方法がわかりません。

つまり、次のように書きます。

TypeError.wrap( SomePythonFunc(...), "foo" );

TypeError : Exception と Exception::wrap が public であるため、wrap のオプションの 2 番目のパラメーターを作成するだけです。

    static void wrap( int condition, string err="default-err" ) {
        if( condition == -1 )
            throw FinalClassConstructor{ err }; // <-- how to do this?
    }

...しかし、::wrap がヒットした最終クラスのコンストラクターを呼び出すにはどうすればよいでしょうか?

4

1 に答える 1

2

あなたがやろうとしていることは、複数の SOLID 原則に反しています。また、基本クラスをその子孫と密結合 (!) にしています。あなたは間違いなくそれを望んでいません。誰が継承するか分からないはずです。

正しく行うには、基本的に自分自身をスローする子クラス内で Wrap 関数をオーバーライドします。あなたのコードでは、StandardError.Wrap(...

しかし、正直なところ、コードに例外を残すだけです。

(WHATEVER CONDITION -> Throw exception) はコード内で完全に問題なく、静的メソッドを使用した別の例外内の例外よりもはるかに読みやすくなっています。

これは、これ以上リファクタリングしてはならない場合です。

于 2014-11-26T07:30:26.057 に答える