WJb Docs - Intermediate

💥 Error Handling Pattern

WJb keeps error handling explicit.

You can choose between two main approaches:

1. Let the action throw (simple failure) 2. Catch the error and route to a dedicated compensation or notification action

---

Approach 1 — Throw and Fail

The simplest and most common pattern:

public override async Task<IActionResult> ExecuteAsync(
    EmailInput input, CancellationToken ct)
{
    await _emailService.SendAsync(input, ct); // may throw
return await CompleteAsync();
}

If an exception occurs:

• The job is marked as Failed
• The error is stored
• Automatic retry can be applied via JobOptions
• The workflow stops for this branch

Use this when a failure should simply stop the current path.

---

Approach 2 — Explicit Error Handling Action

Catch the error inside the action and route to a specific handler:

public override async Task<IActionResult> ExecuteAsync(
    OrderInput input, CancellationToken ct)
{
    try
    {
        await ProcessOrderAsync(input, ct);
return await NextAsync<SendConfirmationAction>(...);
    }
    catch (Exception ex)
    {
        return await NextAsync<HandleOrderFailureAction>(
            new FailureInput
            {
                OrderId = input.OrderId,
                Error = ex.Message
            });
    }
}

Now the workflow continues into a dedicated error-handling path.

---

Example Error Handler

[ActionName("handle-order-failure")]
public sealed class HandleOrderFailureAction : JobAction<FailureInput>
{
    public override async Task<IActionResult> ExecuteAsync(
        FailureInput input, CancellationToken ct)
    {
        await _notifier.NotifyAdminAsync(
            $"Order {input.OrderId} failed: {input.Error}", ct);
await _orders.MarkAsFailedAsync(input.OrderId, ct);
return await CompleteAsync();
    }
}

---

Combining with Retry

You can still use automatic retry for transient errors and fall back to a compensation action only after retries are exhausted (or for permanent errors).

---

Recommended Guidelines

| Situation | Recommended Approach | |----------------------------------|---------------------------------------| | Transient infrastructure error | Throw + automatic retry | | Validation / business rule error | Throw (fail fast) or route to handler | | Need compensation or notification| Catch and Next to error action | | Need to continue despite error | Catch and choose an alternative path |

---

Key Point

Error handling stays visible in the code.

Either the action throws (and WJb records the failure), or the action explicitly decides to continue into an error-handling step.

No hidden global error middleware is required.