EXCEPTION HANDLING · Workflow idea

Treat expected exceptions differently from problems that may recover.

When an operation fails, check whether the issue is a known exception with its own appropriate next step. Route recognized cases separately, retry unexpected failures within a defined limit, and make unresolved problems visible to an owner instead of letting a repeated failure continue unnoticed.

A Roman aqueduct taking shape from architectural sketch to marble.
A little structure. A clearer outcome.
Starts with
A process step fails
Produces
A resolved operation, a separately handled known exception, or a visible unresolved failure awaiting review.
Category
Operations

01 / The starting point

A clear request.
A useful direction.

An unsuccessful operation that needs either a known-exception path or a limited retry

“Recognize expected exceptions, retry other failures only a bounded number of times, and surface any remaining issue for a person to resolve.”
An example request · Make it specific to your team.

02 / The work

4 tasks.
One useful outcome.

Helps teams make routine failure recovery more deliberate and keep expected exceptions from being mistaken for transient problems.

  1. Check the reason an operation failed

    Capture enough information to distinguish an expected exception from an unfamiliar or temporary problem.

  2. Route a recognized exception

    Send a known case to its intended alternate handling path rather than repeatedly attempting the same operation.

  3. Retry unexpected failures within a limit

    Give other failures only the approved number of additional attempts and stop when that limit is reached.

  4. Surface unresolved problems for review

    Show the original issue, attempts made, and affected work to an owner who can decide what to do next.

03 / The result

Something useful.
Something to build on.

A resolved operation, a separately handled known exception, or a visible unresolved failure awaiting review.

AmbactiWorkflow folio · 4 steps

Retry unexpected process errors

Operations · Example outcome

The handoff

A resolved operation, a separately handled known exception, or a visible unresolved failure awaiting review.

Keep in mind

Repeated attempts can duplicate an action, increase load, or conceal a permanent problem. Identify known exceptions precisely, set a safe retry limit, avoid repeating actions that are not safe to repeat, and require an owner to review failures that remain unresolved.

04 / Make it yours

Set the brief.
Set the standard.

A few choices shape the work around your team.

List known exceptions and their outcomes

Define which errors are expected and what safe, separate handling should happen for each one.

Set a bounded retry policy

Choose a maximum number of attempts and verify which operations can safely be repeated.

Assign an owner for unresolved failures

Name who receives issues that exceed the limit and how the team records their resolution.

Test known, temporary, and persistent failures

Confirm recognized cases take their alternate route, temporary failures stop after recovery, and persistent ones become visible.

Put your next idea to work.

Start with your brief. Make the process your own.

Explore more workflows ↗