When multiple aspects advise the same join point, how is @Before ordering determined, and what happens if a @Before throws?

## The advice chain is an onion At a single join point, all matching advices form a nested interceptor chain. Think of each aspect as a layer wrapping the target. Higher-precedence aspects are the **outer** layers. For a call: - **Before** advice runs **outer → inner** (highest precedence first). - The **target** runs in the center. - **After** advice runs **inner → outer** (highest precedence last) — the reverse. ## Determining precedence Spring orders aspects (not individual advice methods across aspects) by: - **`@Order(n)`** annotation (`org.springframework.core.annotation.Order`) on the aspect class, or - implementing **`org.springframework.core.Ordered`** and returning `getOrder()`. **Lower value = higher precedence = runs first for before advice.** `Ordered.HIGHEST_PRECEDENCE` is `Integer.MIN_VALUE`, `LOWEST_PRECEDENCE` is `Integer.MAX_VALUE`. Aspects with no explicit order are effectively unordered relative to each other — do **not** rely on class name or declaration order. ### Within one aspect If a single aspect declares multiple advices matching the same join point, their relative invocation order is **not defined by source order**. Historically Spring didn't guarantee it; even where it's influenced by declaration order in newer AspectJ, the robust design is: **if ordering matters, split the advices into separate aspects and order those.** ```java @Aspect @Component @Order(0) // runs FIRST among before advices class SecurityAspect { @Before("...") void check() { /* authz */ } } @Aspect @Component @Order(10) // runs after SecurityAspect's before class LoggingAspect { @Before("...") void log() { /* entry log */ } } ``` ## What happens when a @Before throws Throwing is `@Before`'s only way to abort. When it throws: 1. **No later before advices** (inner layers) run. 2. **The target method never executes.** 3. The exception **propagates outward** through the already-entered outer layers. Because of the onion nesting, **outer** aspects that had already run their before advice *and* have after/around handling can still react as the stack unwinds: - An outer aspect's **`@After`** (finally-style) advice **still runs**. - Its **`@AfterThrowing`** advice runs, observing the exception. - Its **`@AfterReturning`** does **not** (there was no successful return). - An outer **`@Around`** that wrapped the call sees the exception thrown from its `proceed()` and can catch/translate it. Inner aspects whose before advice never ran do **not** get after advice — they were never entered. ### Concrete trace Given Security(@Order 0) and Logging(@Order 10), both with `@Before` and `@After`, if Security's `@Before` throws: - Security `@Before` runs → throws. - Logging `@Before` never runs (inner, not reached). - Target never runs. - Security `@After`/`@AfterThrowing` — Security's before was the one that threw; whether its own `@After` runs depends on it being a separate advice at the same/enclosing layer. In practice, the exception simply propagates to the caller; only advices at *enclosing* layers relative to the throw point observe it. The safe mental model: **the throw unwinds the partially-built onion**; layers entered before the throw get their finally/after-throwing hooks, layers not yet entered get nothing. ## Design implications (why a principal cares) - **Put security and validation `@Before` at highest precedence** (`@Order(Ordered.HIGHEST_PRECEDENCE)` or a low number) so they gate the call *before* logging/metrics/transaction advice does work that would be wasted or misleading. - **Interaction with `@Transactional`:** the transaction aspect has its own default order (`Ordered.LOWEST_PRECEDENCE` by default). If a `@Before` must run inside or outside the transaction (e.g., validation that should not open a tx vs. auditing that must be transactional), set explicit orders relative to it, or configure the transaction advisor's order. - **Fail-fast placement reduces cost and side effects** — an early throw avoids opening transactions, acquiring locks, or emitting misleading entry logs. - **Avoid order-dependent logic inside one aspect;** model each ordered concern as its own aspect for deterministic, testable sequencing. - **Document orders centrally** — implicit ordering across many aspects is a maintenance hazard; a team convention (e.g., security=0, validation=100, audit=200, logging=300) keeps it legible.