1

例外をスローする@BeforeAdviceを作成し、別の@AfterThrowingでキャッチしようとしましたが、機能しません。

例外がアドバイスではなくメソッドで直接スローされた場合、それは機能します。

アドバイスでスローされた場合、@AfterThrowingは実行されません。

なぜそれがそのように振る舞うのですか？

4

2 に答える 2

0

2つのアドバイスは同じ側面だと思いますか？そうでない場合は、織り順序を定義するための優先順位を宣言しましたか？

とにかく、メソッドの前に何かをしたい場合、および前に行ったことに応じて何かをしたい場合は、@Around代わりにアドバイスを使用する必要があります。そのようにフローを制御するために、例外（コストがかかる）さえ必要ないかもしれません。

于 2012-09-04T11:27:58.003 に答える
0

理由：キャプチャされたメソッド内@AfterThrowingから例外がスローされたイベントをキャッチします。しかし、意味：キャプチャされたメソッドの前（つまり、外部）で何かを実行します。したがって、制御フローは、アドバイスの条件を満たすことができるポイントに到達することはありません。@Before@AfterThrowing

したがって、フランクがあなたに言ったことを実行するか（@Aroundアドバイスを使用）、コードの呼び出し元と呼び出し先の部分を制御できる場合は、これを実行できます（非常に醜い）：

  • @Before("execution(myMethod)")（おそらく例外をスローします）
  • AfterThrowing("call(myMethod)")

私はそれをテストしていませんが、この制御フローのために動作するはずです：

[before call]
call(myMethod)
  [before execution]
  execution(myMethod)
  [after execution]
[after call]

つまり、「実行前」はすでに「通話中」です。

于 2012-09-04T12:07:18.483 に答える