Exception Handling: Exception Handlers, Raise Exception, System vs User Exceptions, AbortTransaction

Quick Answer: OutSystems exception handling is built around three pieces: the Exception Handler block (catch), the Raise Exception node (throw), and the implicit transaction that wraps every Server Action. When a Raise Exception fires or a system error occurs, execution jumps to the nearest matching Exception Handler; if none catches it, the transaction rolls back and an HTTP error is returned.

Exception Handler Blocks on Action Flows

An Exception Handler is a logic-flow element you drop onto a Server Action (or Screen Action) canvas in Service Studio. It defines a catching scope: any exception raised inside the elements wired to that handler triggers the handler's flow. This is OutSystems' direct equivalent of a try/catch construct in C# or Java. The handler flow can log the error with LogMessage, set an output parameter, call AbortTransaction, re-raise the same exception, or simply end the action with a controlled result. Exception Handlers do not automatically retry failed operations — retries require explicit custom logic, and careless retry loops can spin on persistent failures.

A single Server Action can carry multiple Exception Handlers, each scoped to a different exception type. The platform walks the call stack from the point of failure upward, looking for the nearest handler whose Exception property matches (or is a parent of) the raised exception. Matching follows the exception hierarchy: a handler catching a broad System Exception also catches specialized sub-exceptions. If you want only one specific exception, set the handler's Exception property to that exact User Exception; set it to All Exceptions only when you genuinely want a catch-all.

Raise Exception Node

The Raise Exception node is the throwing mechanism. You place it anywhere in an action flow and configure it with a User Exception (or a re-raised caught exception). The moment execution reaches the node, the current flow aborts immediately and the platform searches for a matching Exception Handler up the call stack. Raise Exception is OutSystems' equivalent of the throw keyword — it does not write logs by itself, it does not display a UI message, and it does not manage Timers. Logging only happens when an unhandled exception reaches the top level (platform auto-logging) or when you explicitly call LogMessage inside a handler.

A common pattern is to validate a business rule early and raise a User Exception such as InvalidOrderException when the rule fails. An Exception Handler one level up catches it, logs a structured message, and returns a typed result to the caller instead of letting a raw error propagate.

System Exceptions vs User Exceptions

OutSystems divides exceptions into two categories. Understanding which kind you are dealing with determines how you catch and respond.

The distinction is not about layer (database vs UI). It is about who raises it: the platform (System) or the developer (User). Both categories are catchable by the same Exception Handler mechanism and follow the same propagation and rollback rules.

Transactions: Auto-Commit and AbortTransaction

Every Server Action runs inside an implicit database transaction. The platform auto-commits when the action finishes without an unhandled exception. If an exception escapes unhandled, OutSystems rolls back the entire transaction — every Create, Update, and Delete executed during that action is undone. This is automatic and requires no configuration.

AbortTransaction is a built-in action you call inside an Exception Handler. It rolls back the database writes made so far in the current transaction, then continues executing the handler's flow. The handler can log the failure, set Success = False and an ErrorMessage output parameter, and end normally — returning a controlled result instead of propagating a raw error. The key behavior: AbortTransaction rolls back writes, but does not re-raise. Execution continues in the handler.

Consider a Server Action that writes three order lines, then calls an external REST API that fails. Without an Exception Handler, the unhandled system exception rolls back the three writes and returns an HTTP error. With an Exception Handler wrapping the REST call, you catch the failure, call AbortTransaction to undo the writes, call LogMessage to record it, set an output parameter telling the caller the sync failed, and end cleanly. The caller gets a structured result, not a crash.

On Exception Handling Patterns

The exam expects you to recognize two canonical patterns:

1. Catch-log-return: Exception Handler catches, calls LogMessage, sets output parameters, ends action. No re-raise. Caller receives a controlled result. Use when the caller should not see the raw error (e.g., REST integration failures where you want to return a friendly message).
2. Catch-re-raise: Exception Handler catches, performs cleanup or logging, then re-raises so a higher handler or the platform default rollback still applies. Use when you need side effects but still want the transaction to roll back.

A frequent trap is confusing Exception Handlers with form validation. Input validation happens before the action runs, via the Form widget's Valid property, the Mandatory property, and the Email data type's built-in format check. Exception Handlers catch runtime errors during action execution — they are not a validation mechanism. Another trap is expecting automatic retries: OutSystems Exception Handlers never retry on their own. Any retry loop must be hand-built.