For an argument-validation gate, would you use @Before or @Around, and why?

## The decision, stated plainly - **Pure validation (pass or reject):** use **`@Before`**. - **Anything that needs to alter the invocation** (skip it, change args, change/wrap the return, catch its exceptions): use **`@Around`**. ## Why @Before works for validation A validation gate has exactly two outcomes: *the arguments are acceptable → let the call proceed*, or *they aren't → stop it*. `@Before` maps cleanly onto this: - If the advice returns normally, Spring proceeds to the target automatically. That is the "accept" path — you write nothing. - If the advice **throws**, the exception propagates to the caller and the target is never invoked. That is the "reject" path. Throwing is the *only* mechanism `@Before` has to stop the call, and here it's exactly what you want. ```java @Before("execution(* com.app.OrderService.place(..)) && args(order)") public void validate(Order order) { if (order.getItems().isEmpty()) throw new IllegalArgumentException("order must have items"); } ``` ### Design benefit: intent through constraint `@Before` *cannot* proceed conditionally, cannot mutate the return, cannot swallow the target's exceptions. That limitation is a feature for a validator: anyone reading the aspect knows it only inspects and possibly aborts. It's simpler to reason about, simpler to test, and there's no `proceed()` to forget. ## Why you'd move to @Around `@Around` receives a `ProceedingJoinPoint` and decides *if/how* the target runs. Choose it when validation is not the whole story: 1. **Short-circuit / skip the call** — e.g. return a cached value or a default without invoking the target. `@Before` can't do this (it can only throw, not return a substitute). 2. **Rewrite arguments** — call `pjp.proceed(newArgs)` with sanitized/normalized arguments. `@Before` mutating `getArgs()` is ignored. 3. **Transform the return value** — wrap, redact, or convert what the method returns. 4. **Exception handling around the call** — try/catch `proceed()` to translate or suppress exceptions, add retries, timing on both success and failure paths. ```java @Around("execution(* com.app.PriceService.quote(..))") public Object aroundQuote(ProceedingJoinPoint pjp) throws Throwable { if (cache.has(key(pjp))) return cache.get(key(pjp)); // skip target Object result = pjp.proceed(); // or proceed(newArgs) cache.put(key(pjp), result); return result; } ``` ## Tradeoffs / gotchas - **Power vs. safety:** `@Around` must declare `throws Throwable`, must remember to call `proceed()` (forgetting silently drops the call), and must correctly return `proceed()`'s result. `@Before` has none of these hazards. - **Performance:** negligible difference for validation; both are proxy interceptions. - **Exception type:** whether you throw `IllegalArgumentException`, `ConstraintViolationException`, or a domain exception is a separate design choice; in Spring MVC you'd typically map it via `@ExceptionHandler`/`@ControllerAdvice`. - **Ordering:** if a validation `@Before` and other advice share a join point, use `@Order` so validation runs first (before logging/timing). - **Don't overuse AOP for validation** — bean validation (`@Valid` + JSR-380 annotations) or explicit guard clauses are often clearer for simple field checks; AOP validation shines for cross-cutting, policy-style rules across many methods. ## One-line rule If you only ever *accept or reject*, use `@Before`. The moment you need to *change what happens to the call or its result*, use `@Around`.