遅かれ早かれ、プログラムで何かがおかしくなります。 ファイルは開かず、作業スレッドは作成されず、メモリは割り当てられませんでした...そして、なんとかしてこれを生きる必要があります。 小さなシングルスレッドアプリケーションでは、非常に簡単です。すべての作業を中断して再起動できます。 フェイルファストイデオロギーは軽量プロセスを備えたErlangの基礎の1つであるため、これはErlangが当然の人気を得た要因の1つです。 アプリケーションが大きく、複雑でマルチスレッドである場合、そのスレッドの1つだけで問題が発生した場合、アプリケーション全体を再起動することは合理的ではありません。 Model of Actorsの実装ではさらに悪化します。このモデルでは、数十万のアクターが数十の作業スレッドで作業できます。 あるアクターの問題が他のすべてのアクターに影響することはほとんどありません。



この記事では、 SObjectizerフレームワークでのエラー処理の方法について説明します。

例外-はい、戻りコード-いいえ！

SObjectizer-4が2002年に登場したとき、大きな間違いを犯しました。例外にはリターンコードを使用することを好みました。 そして、SObjectizer-4でのその後の開発経験はすべて、単純な真実を何度も確信しました。開発者がエラーを予測できる場合、それは彼によって無視されます。 したがって、SObjectizer-5を作成するときに、例外を使用してエラーを報告することにしました。



それは正しい選択でした。 紛争「戻りコードに対する例外」では、槍はまだ壊れていますが、私たちの経験は、例えばエージェントのサインアップやエージェントの協力の登録エラーなど、誤って見逃すことができない場合にのみ開発が勝つことを示しています。



そのため、SObjectizer-5は、この操作またはその操作を実行できない場合に例外をスローします。 ほとんどの場合、これらの操作はSObjectizerにすでに登録されているエージェントによって実行されます。 エージェントが例外に遭遇した場合はどうすればよいですか？

通常のエージェントは例外をスローすべきではありません！

これは、例外に関してエージェントに存在する主なルールです。 イベントの処理中にエージェントが例外を受け取った場合（SObjectizerまたは他の誰かが例外をスローするかどうかは関係ありません）、エージェントはこの例外をスローしません。

説明は簡単です。 SObjectizerのエージェントには、独自の作業コンテキストがありません。 大まかに言えば、エージェントは自分が作業するワークスレッドを所有していません。 作業コンテキストは、次のイベントの処理中にエージェントが接続されているディスパッチャによって提供され、その後、別のエージェントに提供できます。 特定のエージェントが外部に例外をスローすると、この例外はディスパッチャに送られ、作業コンテキストが強調表示されます。 アプリケーションがディスパッチャにアプリケーションを強制終了するか、動作を継続させるかを決定させたくない場合、このアプリケーションのエージェントは例外処理を自分で処理する必要があります。



理想的には、これは、エージェントイベントがメソッド以外であることを意味します。 しかし、これは理想的なケースです。 C ++のnoexceptメカニズムは良いことですが、noexceptメソッドの例外が到着しないことを保証するだけです。 同時に、非例外メソッドがnoexceptメソッドで呼び出された場合、飛び出すことができ、コンパイラーは手を打つことはありません。 また、例外が引き続き発生する場合は、std :: terminate（）に直接進みます。 これは必ずしも私たちに適しているわけではありません。 私たちが住んでいるその不完全な世界にいるにはどうすればいいですか？

SObjectizerは、エージェントから流出した例外への対応方法を促すことができます

たわごとは時々 発生するため、エージェントに例外のない保証を提供することを約束したとしても、間違いを犯す可能性がありますが、それでも例外は外に出ます。 ディスパッチャーは彼を捕まえて、次に何をすべきかを決定します。



これを行うために、ディスパッチャは問題のあるエージェントでso_exception_reaction（）仮想メソッドを呼び出します。 このメソッドは、次の値のいずれかを返します。

• so_5 :: abort_on_exception。 これにより、std :: abort（）が呼び出され、アプリケーション全体が中断されます。
  
  
  
  
• so_5 :: shutdown_sobjectizer_on_exception。 この値は、エージェントが基本的な例外保証（つまり、リソースリークや何かの損傷がないこと）を提供するが、さらなる作業を続ける意味がないことを意味します。 したがって、エージェントは、エージェントがイベントを処理できない特別な状態に移行し、SObjectizer Environmentはstd :: abort（）を呼び出さずに正常に完了します。 同時に、登録されているすべての協同組合が適切に登録解除されるため、他のエージェントは通常どおり作業を完了し、リソースをクリーンアップできます。 複数のSObjectizer Environmentがアプリケーションで同時に機能することに注意してください。 shutdown_sobjectizer_on_exceptionの場合、例外がキャッチされたSObjectizer Environmentのみが終了します。
  
  
  
  
• so_5 :: deregister_coop_on_exception。 この値は、エージェントが基本的な例外保証を提供し、アプリケーションがこのエージェントとその協力なしで作業を続行できることを意味します。 したがって、エージェントは特別な状態に移行され、その協力は通常の方法で登録解除されます（これにより、他の協力エージェントが正常に作業を完了できるようになります）。
  
  
  
  
• so_5 :: ignore_exception。 この値は、エージェントが強力な例外保証を提供することを意味します（つまり、リソースリークや何かへの損傷がないか、エージェントが正しい状態のままになります）。 したがって、ディスパッチャは例外が存在しないかのように、単に無視します。

ignore_exceptionのようなオプションを持つことは、通常のエージェントが外部に例外をスローしてはならないと述べられた後、奇妙に見えるかもしれません。 ただし、実際には、この値を持つことは、非常に単純なイベントハンドラーを持つエージェントにとって便利です。 たとえば、エージェントはタイプM1のメッセージを受信し、それをタイプM2のメッセージに変換します。 変換中に例外が発生する場合がありますが、効果はほとんどありません。エージェントの状態は壊れておらず、メッセージM2は失われています。メッセージは何らかの理由で失われる可能性があります。 このような場合、各イベントハンドラーにtry-catchブロックを含めるよりも、ディスパッチャが例外を無視するように、単純なエージェントから例外を飛ばす方が簡単です。



したがって、プログラマーは、エージェントに最適なオプションを自分で決定し、so_exception_reaction（）メソッドをオーバーライドして、SObjectizerに例外をキャッチした後の方法を通知できます。

using namespace so_5; //  ,    M1  mbox- src    //   M2  mbox- dest. ,     // , . class my_simple_message_translator final : public agent_t { public : my_simple_message_translator( context_t ctx, mbox_t src, mbox_t dest ) : agent_t( ctx ) { so_subscribe( src ).event( [dest]( const M1 & msg ){ send< M2 >( dest, ... );} ); } //  SO-5,     . virtual exception_reaction_t so_exception_reaction() const override { return ignore_exception; } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

協力の例外

agent_t :: so_exception_reaction（）の標準実装は、エージェントが属する協力のexception_reaction（）メソッドを引き出します。 つまり デフォルトでは、エージェントは連携から例外応答を継承します。 そして、この反応は、協力を登録するときに設定できます。



例：

 //    ,     //        . env.introduce_coop( []( coop_t & coop ) { coop.set_exception_reaction( deregister_coop_on_exception ); coop.make_agent< some_agent >(...); ... } );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、SObjectizerでは、例外に対する応答をエージェントレベルで設定できます。これが行われていない場合、エージェントの協力に対して指定された例外に対する応答が使用されます。



しかし、協力を作成するときにset_exception_reaction（）メソッドが呼び出されない（そしてほとんどの場合、呼び出されない）場合はどうなりますか？



プログラマがcoop_t :: set_exception_reaction（）を明示的に呼び出さなかった場合、coop_t :: exception_reaction（）は特別な値-so_5 :: inherit_exception_reactionを返します。 この値は、協力が親の協力の排除反応を継承することを示します。 この親の協力が存在する場合、SObjectizerはexception_reaction（）を呼び出します。 親の協力もso_5 :: inherit_exception_reactionを返す場合、SObjectizerは親の協力の親などに対してexception_reaction（）を呼び出します。



最終的に、次の親の協力がないことが判明するかもしれません。 この場合、SObjectizerはenvironment_t全体に対してexception_reaction（）を呼び出します。 そして、すでにenvironment_t :: exception_reaction（）は値so_5 :: abort_on_exceptionを返します。 これにより、std :: abort（）を呼び出すことにより、アプリケーション全体が崩壊します。







ただし、プログラマはSObjectizer環境全体に対して例外応答を設定できます。 これは、起動時にSObjectizerのプロパティを設定することで実行されます。

 so_5::launch( []( environment_t & env ) {...}, []( environment_params_t & params ) { params.exception_reaction( shutdown_sobjectizer_on_exception ); ... } );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

少し中間的な要約

したがって、エージェントが例外をスローした場合、SObjectizerはそれをインターセプトし、agent_t :: so_exception_reaction（）を呼び出して、エージェントに例外をどうするかを尋ねます。 プログラマーがso_exception_reaction（）を再定義しなかった場合、例外への応答は、エージェントが入力する協力によって決定されます。



通常、コラボレーションは、親から例外応答を継承することをSObjectizerに伝えます。 SObjectizerは、保護者の協力を求めます。 その後、親と親の協力など。 そして、親がなくなると、SObjectizerは、environment_tから例外への応答を要求します。この中で、問題のあるエージェントは動作します。 デフォルトでは、environment_tは、std :: abort（）への呼び出しによってアプリケーションを中断する必要があることを通知します。 したがって、プログラマはさまざまなレベルで例外の発生に影響を与えることができます。

• エージェント自体で、エージェントイベント内のすべての例外をキャッチするか、so_exception_reaction（）をオーバーライドします。
• エージェントの協力または親の協力において;
• SObjectizer環境では、エージェントとコラボレーションが機能します。

協力の登録解除にどのように対応しますか？

上記のように、SObjectizerは、さまざまな方法でエージェントからスローされた例外に応答できます。 たぶん、例えば、問題のある協力だけを登録解除するでしょう。 しかし、この反応のポイントは何ですか？ 結局のところ、協力はアプリケーションに適用されたいくつかの問題を解決し、それが解決しなければ、それは存在しなかったでしょう。 そして、この協力は突然消えます...どのようにそれを調べ、どのようにそれに反応するのですか？



SObjectizerを使用すると、何らかの協力が登録解除されたという通知を受け取ることができます。 いくつかの点で、このメカニズムはErlangのプロセスを監視する機能に似ています。たとえば、erlang：monitor（process、Pid）を呼び出すことができ、Pidプロセスが終了すると、メッセージ{'DOWN'、...}が受信されます。



SObjectizerには、登録解除イベントで通知機能を「ハング」させる機能があります。 notifierは、コラボレーションの登録解除が完了するとSObjectizerが自動的に呼び出すファンクターです。 SObjectizerは、登録解除された協力の名前と登録解除の理由の両方をこのファンクターに渡します。 このファンクターは、アプリケーションが必要とすることを実行できます。 たとえば、協力関係の消失について関心のあるエージェントにメッセージを送信できます。 または、単に協力関係を再登録できます。

 //       //     -  . #include <iostream> #include <so_5/all.hpp> void start_coop( so_5::environment_t & env ) { env.introduce_coop( [&]( so_5::coop_t & coop ) { struct raise_exception : public so_5::signal_t {}; //     . //        . auto agent = coop.define_agent(); agent.on_start( [agent] { so_5::send_delayed< raise_exception >( agent, std::chrono::seconds(1) ); } ) .event< raise_exception >( agent, [] { throw std::runtime_error( "Just a test exception" ); } ); //  SObjectizer-     . coop.set_exception_reaction( so_5::deregister_coop_on_exception ); //  ,      // ,   ,     . coop.add_dereg_notificator( []( so_5::environment_t & env, const std::string & coop_name, const so_5::coop_dereg_reason_t & why ) { std::cout << "Deregistered: " << coop_name << ", reason: " << why.reason() << std::endl; if( so_5::dereg_reason::unhandled_exception == why.reason() ) start_coop( env ); } ); } ); } int main() { so_5::launch( []( so_5::environment_t & env ) { //     . start_coop( env ); //     . std::this_thread::sleep_for( std::chrono::seconds( 5 ) ); //  . env.stop(); } ); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Slangには、Erlangのような既製のスーパーバイザーシステムはありません。 どういうわけか私は彼女なしで行うことができました。 ただし、適用されたタスクに必要な場合は、通知機能に基づいて類似のものを収集できます。

最後の哲学的発言

C ++は安全でない言語です。 そして、例外の安全性の少なくとも基本的な保証を提供するコードを書くには、開発者のいくらかの努力が必要です。 したがって、アクターをC ++で実装する場合、フェイルファーストの原則の使用に注意する必要があります。 これはErlangで良いです-プロセスで問題が見つかった場合、彼らはプロセスを強制終了し、その後Erlang VMはその後すべてをクリーンアップし、対応するスーパーバイザーは失敗したプロセスではなく新しいプロセスを開始しました。



C ++では、すべてのエージェントは同じプロセス内に存在します。 したがって、エージェントの1つが十分に実装されていない場合、リソースのリークやプロセスのメモリ内の何かへの損傷を考慮して、登録解除されたエージェントの代わりに登録解除とそれに続く新しいエージェントの作成は解決策ではないかもしれませんが、さらに大きな問題です。



これが原因で、SObjectizerでは、デフォルトで、エージェントの1つが例外をスローすると、アプリケーション全体が中断されます。 プログラマーがこれに満足せず、リアクションを他のリアクション（特にignore_exceptionリアクション）に変更しようとする場合、例外の安全性を確保するためにエージェントコードを慎重に検討し、慎重にチェックする必要があります。

おわりに

おそらくこの記事では、SObjectizerの主な特徴的な機能についての話を締めくくります。 何か新しいものが登場したら、SObjectizerに関する以下の記事をリリースします。 まあ、または興味深い質問に出くわした場合、どれに完全な答えを出すのは困難です。



同時に、この機会を利用して、 10月22日にミンスクで開催されるCorehard C ++ Autumn 2016カンファレンスにご招待します。 また、C ++に関連したアクターのモデルに関するレポートがあります。 SObjectizerを含む。