Asterisk dialplan exceptions and application failures

Separate three different control paths

An Asterisk exception, an application returning a failure status and a channel ending are not interchangeable events. The special e extension catches unhandled i, t or T cases in its context, while RaiseException() explicitly transfers control to e. TryExec() instead returns to the next priority and reports the invoked application result in TRYSTATUS.

Decide which event the dialplan must handle before adding a branch. An ordinary application failure is not documented as an automatic jump to e, and an e handler is not a universal catch block for every unsuccessful call operation.

Scope the e handler to the executing context

Asterisk documents e as a catchall for i, t and T when the corresponding special extension does not exist. A local i, t or T therefore handles that case before e. The handler is part of the current context, not a process-wide error route.

For RaiseException(reason), Asterisk jumps to e in the current context and sets EXCEPTION(). If that context has no e extension, the documented result is hangup. Preserve the context, extension and priority at the raise point as well as the handler context actually loaded.

Read exception evidence before replacing it

EXCEPTION(reason) can report INVALID, ERROR, RESPONSETIMEOUT, ABSOLUTETIMEOUT or a custom reason supplied to RaiseException(). The context, exten and priority fields identify where the exception occurred. Capture or copy those fields at the start of e before another branch or nested exception obscures the original location.

Treat a custom reason as a dialplan-controlled label, not proof of root cause. Keep it bounded to an allow-listed vocabulary and avoid embedding credentials, caller data or raw external input in the reason or logs.

Use TryExec for explicit application-result branching

TryExec(appname(arguments)) always returns to the dialplan and sets TRYSTATUS to SUCCESS, FAILED or NOAPP. SUCCESS means the invoked application returned zero; it does not prove the business outcome, a completed call or a later route. NOAPP distinguishes a missing or unspecified application from a non-zero application return.

Read and branch on TRYSTATUS immediately. A later TryExec() can replace it, and wrapping an application changes control flow that may previously have stopped or redirected execution. Confirm the application and module exist on the target Asterisk branch before rollout.

Keep cleanup and caller treatment explicit

An exception handler should record a correlation-safe reason and origin, perform only idempotent cleanup, choose an explicit caller treatment and then end or transfer control deliberately. Do not assume reaching e runs the h extension in a particular order, restores channel state, rolls back external work or returns to the priority after RaiseException().

If a Gosub owns resources, define whether it returns a status, raises a custom exception or performs its own cleanup. Avoid a handler that re-enters the failing route, raises again without a guard or silently sends every failure to the same announcement.

Test each trigger as a separate acceptance case

In an authorized staging path, exercise invalid IVR input, response timeout, absolute timeout, one allow-listed custom RaiseException() reason, a TryExec() success, a non-zero application return and a deliberately unavailable application where safe. Record the loaded context, origin priority, exception fields or immediate TRYSTATUS, selected treatment and final channel outcome.

Retest the same route with local i, t or T handlers present, plus an unrelated control route. Remove temporary logging and confirm sensitive values were never captured. No PBX, module set, dialplan, channel, exception, timeout or live call was tested for this guide.

Do not stop at a successful dialplan write

The AMI dialplan diagnostic continues from the action response into application availability, arguments, return behavior and priority sequence.