Exception-Oriented Programming

• Exception-Oriented Programming is a paradigm that treats failures and abnormal situations as primary design constructs rather than incidental error-handling mechanisms.
• It unifies normal and exceptional control flows using constructs like seqor and prioritized operators to support precise rollback, compensation, and recovery.
• EOP integrates techniques such as compensation programming, static effect tracking, and automated exception flow analysis to enhance system robustness.

Exception-Oriented Programming (EOP) is a programming style in which exceptional, failure, and abnormal situations are treated as first-class design concerns rather than incidental try/catch boilerplate. Across work on imperative control constructs, logic programming, long-running transaction compensation, smart-contract specification, effect systems, and exception-aware developer tooling, EOP is characterized by explicit modeling of failure, recovery, fallback, compensation, and propagation. The literature does not present a single canonical EOP calculus or language; instead, it exhibits a family of formulations in which normal and exceptional paths are specified with comparable precision, often with formal support for ordering, history sensitivity, or static control (Colombo et al., 2014, Kwon, 2013, Kwon, 2016).

1. Foundational semantics of failure and prioritized choice

One influential formulation recasts selection and exception handling around a single construct, seqor(G_1,\ldots,G_n), whose semantics is to sequentially choose the first successful statement $G_i$ and then proceed with executing $G_i$. In this view, every statement yields either success or failure, boolean conditions are treated as statements, and “false is replaced by failure.” The main execution judgment is $ex(\mathscr{P}, G, \mathscr{P}')$, meaning that executing statement $G$ in program $\mathscr{P}$ succeeds and produces a new program $\mathscr{P}'$. If no $G_i$ succeeds, execution returns failure, potentially with a list of error codes; rollback of partial state updates is delegated to the machine before the next alternative is tried (Kwon, 2013).

This unification makes if-then-else, switch, and try-catch instances of a common sequential-choice operator. For example, if cond then S else T is expressed as seqor(cond; S, T), and a chain of fallbacks such as robust message sending becomes seqor(A, B, C). The resulting control-flow model is lexical, ordered, and rollback-aware rather than nonlocal and type-dispatch-driven. A central EOP implication is that failure is not a side channel attached to ordinary control flow; it is a primitive semantic outcome that organizes the control structure itself (Kwon, 2013).

A closely related logic-programming line introduces prioritized sequential-disjunctive goals $G_0 \add G_1$ and prioritized sequential-conjunctive clauses $D_0 \add D_1$. Operationally, $G_0 \add G_1$ means: try $G_i$0; if it succeeds, commit and do not leave a choice point for $G_i$1; if it fails, attempt $G_i$2. The same priority structure applies at the clause level, allowing high-level expression of default reasoning, if-then-else, cut, and exception handling without relying on Prolog’s ad hoc control operators. In this setting, the fallback branch is an explicit failure-handling routine rather than an implicit search artifact (Kwon, 2016).

These formulations situate EOP at the level of language semantics. Failure, priority, and handler selection are represented by ordinary program constructs, not by external conventions. A plausible implication is that EOP begins where exceptional control flow becomes compositional enough to support formal reasoning about commitment, rollback, and fallback ordering.

2. History-sensitive compensation and monitor-oriented architectures

EOP becomes substantially more complex in long-running, distributed, and security-critical computations, where rollback is impossible or undesirable and semantic undo must be derived from execution history rather than current local state. In compensation programming for web service compositions, the key questions are when to trigger compensation, what to compensate, how to compensate, and which strategy to select when several are possible. Traditional exception handling is state-centric and instantaneous, whereas compensation depends on the runtime execution flow and the history of behaviour of the system at the moment of failure (Colombo et al., 2014).

Monitor-oriented compensation programming addresses this by combining runtime monitors, DATEs, a compensation manager, and compensating automata. Runtime monitors observe executions as event streams including method calls, returns, exception throws, and domain-level events such as bankError, courierError, and userCancel. They maintain internal state over control-flow patterns, timers, retries, thresholds, and user classifications, and they emit compensate or continue signals. Conceptually, a monitor can be viewed as an event-driven automaton $G_i$3, with DATEs extending this model through timers, conditions, and channel outputs (Colombo et al., 2014).

The compensation manager and compensating automata answer what and how by maintaining a compensation stack driven by execution history. A compensating automaton listens to system events, decides whether to install compensation instructions, and pushes those instructions onto a stack to be executed later, typically in reverse chronological order. The framework also supports scoping through boxes: compensations installed within a box are purged when execution reaches the end of the box, delimiting which effects remain compensatable. This makes compensation eligibility a function of the trace so far, not of the immediate machine state (Colombo et al., 2014).

Architecturally, the system emits an event $G_i$4 and waits for a continue signal. The monitor processes $G_i$5 and emits either compensate or continue. The compensation manager also processes $G_i$6, updates its stack, and, when compensation has been requested, emits compensation instructions to the system in stack order while continuing to process new events. The system resumes only when it receives two continue signals, one from the monitor and one from the compensation manager. In EOP terms, the exceptional path is not stack unwinding but a history-sensitive dialogue among the system, monitors, and compensators (Colombo et al., 2014).

The e-procurement case study illustrates this style concretely. Users create virtual credit cards, load money, transfer funds, order goods, initiate bank payment, and book a courier. Failures include bank error, courier error, and user cancellation; cancellation or reversal usually incurs a charge; some operations cannot be canceled after shipment has started. The framework supports at least three courier strategies, at least three banking strategies plus a fourth for blacklisting and credit card blocking, and nine different compensation strategies across three user types and three error types. This is an EOP formulation in which exceptional policy is rich, centrally modeled, and explicitly dependent on history and classification (Colombo et al., 2014).

3. Contractual and normative specification of exceptional behaviour

A different strand places exceptional behaviour inside domain-specific contract languages. EROP—Events, Rights, Obligations, Prohibitions—is a contract specification language for smart contracts that decomposes a contract into events, rights, obligations, and prohibitions. Its central state abstraction is the ROP set of each role player, and its rules describe how that normative state evolves under both normal and abnormal scenarios. Although the term EOP is not used directly, the language is built around explicit handling of business and technical failures, unexpected sequences of events, and violations of rights, obligations, and prohibitions (Delchev et al., 2023).

A contract in EROP has a declaration section defining role players, business operations, and composite obligations, and a rule section whose left-hand side matches events and constraints while the right-hand side updates ROP sets, outcome flags, and reset actions. Event patterns have fields such as botype, originator, responder, and outcome, and constraints may include OutcomeConstraint, TimeDirectComparison, TimePartialComparison, HistoricalQuery, and RopConstraint. This rule-based structure makes exceptional contingencies explicit rather than secondary (Delchev et al., 2023).

The Buyer–Seller case study is intentionally exception-rich. Ten clauses model normal buying, buy-request failures, payment failures, and corrective behaviour when failures accumulate. One rule marks the first business failure and, on subsequent failure, executes reset buyer and reset seller, thereby resetting the ROP sets of the role players. In effect, the contract embeds a global exception-handling policy over normative state, not merely over control flow (Delchev et al., 2023).

Compilation is central to this framework. The EROP compiler translates high-level rules into Augmented Drools for execution by the Contract Compliance Checker. The translation pipeline includes lexical analysis with ANTLR, syntax analysis, semantic analysis, intermediate code generation into rule structure classes such as Rule, EventMatchCondition, Constraint, and RhsAction, and code generation through a Translator class and XML-based Lookup. Because Drools does not directly support EROP’s if/else structure inside rule actions, the compiler splits an EROP rule containing if/else into multiple Drools rules, one for the if branch and one for the else branch. This means that exception-oriented branching is preserved as explicit executable rules rather than compiled away into opaque imperative code (Delchev et al., 2023).

The CCC architecture supplies the runtime environment, with a Drools Engine, Event Queue / Event Logger, Relevance Engine, Time Keeper / Java Timers, Translation Engine, and Database. At runtime, events are matched against derived rules, rights and obligations are added or removed, failures are marked, and entire ROP sets can be reset. A plausible implication is that EOP, in this contractual formulation, is less about stack-based exceptions than about norm-governed recovery and enforcement in event-driven systems.

4. Static control of exceptional effects

EOP also appears in static form through type-and-effect systems. CallE is an object-oriented language whose key design choice is that effects are method calls. The core judgment is $G_i$7, where $G_i$8 is the effect list of method selectors associated with evaluating $G_i$9. For a method call, the effect of the receiver, the effects of the arguments, and the method selector itself are combined. Effects are ordered by a sub-effect relation $ex(\mathscr{P}, G, \mathscr{P}')$0, with reflexivity, transitivity, composition, a top effect *, a bottom empty effect, and an indirect rule under which a method token is itself a sub-effect of the effects in its annotation (Gariano et al., 2019).

This design provides static control over privileged operations. The restriction form restrict[ε̄] e is well-typed only when the actual effects of e are a sub-effect of the declared bound $ex(\mathscr{P}, G, \mathscr{P}')$1. The paper uses this to prevent code from performing operations such as querying a database, modifying GUI widgets, exiting the program, or performing network communication, and to ensure determinism by excluding non-deterministic primitives like random number generation or file reading from the allowed effect set (Gariano et al., 2019).

In an EOP interpretation, the same mechanism can represent exception-related behaviour directly as method-call effects. The provided examples include Exception.#throw(Exception e) effect[Exception.#throw] and Error.#raise(Error e) effect[Error.#raise]. Under this reading, throwing an exception, logging, aborting, querying a database, modifying a GUI, and spawning a thread are all uniformly tracked as named effects. Code that must not throw or must not call privileged operations simply omits those effects from its annotation or places a restrict[] boundary around the relevant expression (Gariano et al., 2019).

The indirect rule is especially important because it reduces annotation burden in the same way that checked exception propagation reduces the need to enumerate all low-level sources individually. A method annotated with a higher-level effect can call wrappers whose annotations are sub-effects of that effect. This suggests an EOP style in which exceptional behaviour is surfaced in signatures, made compositional through sub-effect reasoning, and constrained statically rather than discovered only at runtime.

5. Empirical practice and automated assistance

Empirical work shows why EOP remains difficult in ordinary software practice. A large exception-flow study over 10,110 try blocks, 11,797 catch blocks, and over 77,000 exception flows across 16 open-source Java and C# libraries and applications found that each try block has up to 12 possible potentially recoverable yet propagated exceptions. It also found that 22% of the distinct possible exceptions can be traced back to multiple methods, with an average of 1.39 and a maximum of 34, and that there is a lack of documentation of the possible exceptions and their sources. At the same time, 93% of Java and 71% of C# exceptions identified in the study could be retrieved from the external documentation of dependencies, showing that exception flow analysis can recover critical information unavailable from local code alone (Pádua et al., 2017).

The same study classifies handler strategies as Specific, when the caught type equals the possible exception type, and Subsumption, when the catch type is a superclass. It reports heavy use of subsumption, widespread diversity in possible exceptions per try, and language-level differences in actions such as ThrowWrap, ThrowNew, NestedTry, Continue, and Todo. These findings underline a structural challenge for EOP: exception handling is typically many-to-many, under-documented, and only weakly aligned with exception-specific recovery semantics (Pádua et al., 2017).

Mobile-app evidence is similarly strong. An empirical study of 246 exception-related bugs across 10 Android apps found that about 80% of exception bugs cause app crashes or unstable states and about 13% cause feature malfunction or degraded behavior. In about 16% of the fixes, developers swallow exceptions, and only about 42% of the fixes add genuine repairing code in catch blocks. The same work notes that the Android framework contains more than 3,400 classes, about 35,000 methods, and more than 260 exception types, that 51% of the observed exception bugs are caused by Android methods, and that about 58% involve runtime exceptions (Nguyen et al., 2019).

To address this, ExAssist combines XRank and XHand. XRank models “potential exceptions toward a method” as fuzzy sets and ranks likely exception types for a code snippet from its set of method calls. XHand recommends repairing method-call sequences in handlers by using a J48 decision tree for the first repair method and a 2-gram model with Witten–Bell smoothing for subsequent methods. Trained from 4,000 top free Android apps, the system reports top-1 and top-3 accuracy of 70% and 87% for XRank, and 89% and 96% for XHand. These results suggest that EOP can be operationalized not only as a language design principle but also as an IDE workflow in which likely failures and likely repairs are recommended during coding (Nguyen et al., 2019).

6. Conceptual status, misconceptions, and open problems

A common misconception is that EOP denotes a single extension of try/catch. The surveyed work indicates a broader and less standardized picture. One line treats failure as the primitive outcome of statements and unifies branching and exception handling through seqor; another provides prioritized goal and clause operators in logic programming; another externalizes exceptional policy into monitors, DATEs, and compensating automata; another frames failures through events, rights, obligations, and prohibitions; another uses type-and-effect annotations over method calls; and some of these papers state explicitly that the term EOP is not used directly even though the design is exception-centric (Kwon, 2013, Kwon, 2016, Delchev et al., 2023, Gariano et al., 2019).

A second misconception is that exception handling is adequately captured by local state and exception type. The compensation literature argues the opposite for long-running systems: whether and how to compensate depends on runtime execution flow, concurrency, retries, user classification, and scoping boundaries. The empirical literature similarly shows that a single try often corresponds to multiple possible exceptions and multiple source methods. This suggests that mature EOP must often be trace-based or flow-aware rather than point-based (Colombo et al., 2014, Pádua et al., 2017).

The research record also exposes open problems. In the seqor formulation, rollback is conceptually required but its exact granularity is not formally specified, especially for external effects and concurrency. In CallE, there is no automatic inference algorithm for annotations, and global state or static fields are only accommodated indirectly through pseudo-methods. In empirical mining and recommendation, dataset quality and platform specificity remain threats to generalization. In contract-centric systems, deontic concepts are powerful but subtle, and the translation from high-level clauses to executable rules requires careful semantic preservation (Kwon, 2013, Gariano et al., 2019, Nguyen et al., 2019, Delchev et al., 2023).

Taken together, these works support a technically precise synthesis: EOP is best understood as a research umbrella for programming techniques in which failure, exceptional flow, compensation, and recovery are explicit objects of semantics, architecture, specification, typing, or tooling. In some settings this means ordered alternatives and rollback; in others it means prioritized proofs, compensation stacks, rule-based normative repair, effect bounds, or mined handler patterns. The shared principle is not a single syntax but the elevation of exceptional behaviour to a primary, analyzable dimension of software design.