Data-oriented exception handling

Exception handling mechanisms have been introduced into programming languages in an effort to help deal with runtime irregularities. These mechanisms aim to improve code reliability by providing constructs for sectioning code into exception scopes (e.g. Java try blocks) and exception handlers (e.g. Java catch blocks). Whilst exception handling mechanisms have been the focus of much research over the past years, empirical studies have only focused on characterising exception handling code of Java and C# programs. There exists little empirical evidence on how exception handling mechanisms are used to develop software with other programming languages. Moreover, to date there exists no empirical study which has examined the structure of exception scopes across software projects. We address these shortcomings by examining the commonalities and differences of both exception scopes and handlers implemented with a wider range of languages. To this end, we analysed 50 software projects, containing code developed in C++, JavaScript, PHP, Java and C#. More than 9 million lines of code and over 20,000 exceptional code blocks were analysed. Our findings revealed significant differences in the frequency, structure and length of exception scopes and exception handlers across languages. This finding suggests that certain exception handling mechanisms are less explored by programmers using certain programming languages. However, regardless of language, exception handlers remained simplistic and in general only ever one handler was associated with each scope. Finally, our analysis confirms the existing belief that developers often pay little attention to developing exception scoping and handling behaviour.

Some legacy programming languages, e.g., C, do not provide adequate support for exception handling. As a result, users of these legacy programming languages often implement exception handling by applying an idiom. An idiomatic style of implementation has a number of drawbacks: applying idioms can be fault prone and requires significant effort. Modern programming languages provide support for structured exception handling (SEH) that makes idioms largely obsolete. Additionally, aspect-oriented programming (AOP) is believed to further reduce the effort of implementing exception handling. This paper investigates the gains that can be achieved by reengineering the idiomatic exception handling of a legacy C component to these modern techniques. First, we will reengineer a C component such that its exception handling idioms are almost completely replaced by SEH constructs. Second, we will show that the use of AOP for exception handling can be beneficial, even though the benefits are limited by inconsistencies in the legacy implementation.

Exception handling is widely regarded as a necessity in languages today and almost every currently used for professional software development supports some form of it. However, spreadsheet systems, which may be the most widely used type of programming language today in terms of number of users using it to create programs (spreadsheets), have traditionally had only extremely limited support for exception handling. Spreadsheet system users range from end users to professional programmers and this wide range suggests that an approach to exception handling for spreadsheet systems needs to be compatible with the equational reasoning model of spreadsheet formulas, yet feature expressive power comparable to that found in other languages. We present an approach to exception handling for spreadsheet system users that is aimed at this goal. Some of the features of the approach are new; others are not new, but their effects on the properties of spreadsheet systems have not been discussed before in the literature. We explore these properties, offer our solutions to problems that arise with these properties, and compare the functionality of the approach with that of exception handling approaches in other languages.

Exception handling is an important feature of the tool-set that enables the building of fault-tolerant concurrent and distributed programs. While transactional distributed systems have been studied for a long time, distributed exception handling techniques are only now evolving towards maturity, especially within asynchronous multi agents or component based systems. In this paper, we review two recent proposals for distributed exceptions handling systems (DEHS), namely SaGE and Guardian, in the light of what the Erlang programming language brings to the table : native constructs for concurrency, distributedness and exception handling across processes. We expand on the merits and possible drawbacks of these systems. We advocate the need to introduce the notion of resumption, an often downplayed feature of EHSs, to modern day DEHS, in order to address the problem of multi agent systems facing the “real world”.KeywordsMulti Agent SystemException HandlingService ExecutionMethod InvocationCommon LispThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Component-based software systems built out of reusable software components are being used in a wide range of applications which have high dependability requirements. In order to accomplish the required levels of dependability, it is necessary to incorporate into these complex systems means for to cope with software faults. Exception handling is a well-known technique for adding forward error recovery to software systems supported by various mainstream programming languages. However, exception handling for component-based applications at the architectural level introduces new challenges which are not addressed by traditional exception handling systems, such as unavailability of source code, specially when off-the-shelf components are employed. In this paper, we present an exception handling system which adds fault tolerance to component-based systems at the architectural level. Our solution considers issues which are specific to component-based applications, such as unavailability of source code. We also present a framework which implements the proposed exception handling system for applications built using the C2 architectural style.KeywordsService RequestException HandlingArchitectural LevelDependable SoftwareClient ComponentThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

This paper presents an empirical study whose goal was to investigate the exception handling strategies adopted by Java libraries and their potential impact on the client applications. In this study, exception flow analysis was used in combination with manual inspections in order: (i) to characterize the exception handling strategies of existing Java libraries from the perspective of their users; and (ii) to identify exception handling anti-patterns. We extended an existing static analysis tool to reason about exception flows and handler actions of 656 Java libraries selected from 145 categories in the Maven Central Repository. The study findings suggest a current trend of a high number of undocumented API runtime exceptions (i.e., @throws in Javadoc) and Unintended Handler problem. Moreover, we could also identify a considerable number of occurrences of exception handling anti-patterns (e.g. Catch and Ignore). Finally, we have also analyzed 647 bug issues of the 7 most popular libraries and identified that 20.71% of the reports are defects related to the problems of the exception strategies and anti-patterns identified in our study. The results of this study point to the need of tools to better understand and document the exception handling behavior of libraries.

A model based on a Petri net (PN) is proposed for controlling flexible manufacturing systems (FMSs). The model can describe not only normal sequential processes but also interruptive exceptional handling processes by means of simple structures. A layered structure and two types of token are introduced into a PN to describe exception handling and error recovery. An application in which this model was used to program a programmable logic controller (PLC) is described. The description of cell control can be simplified by the model. >

We provide a rigorous framework for language and platform independent design and analysis of exception handling mechanisms in modern programming languages and their implementations. To illustrate the practicality of the method we develop it for the exception handling mechanism of Java and show that its implementation on the Java Virtual Machine (JVM) Is correct. For this purpose we define precise abstract models for exception handling in Java and in the JVM and define a compilation scheme of Java to JVM code which allows us to prove that, in corresponding runs, Java and the JVM throw the same exceptions and with equivalent effect. Thus, the compilation scheme can, with reasonable confidence, be used as a standard reference for Java exception handling compilation.

Exception handling mechanisms are intended to help developers build robust systems. Although an exception handling mechanism provides a basis for structuring source code dealing with unusual situations, little information is available to help guide a developer in the appropriate application of the mechanism. In our experience, this lack of guidance leads to complex exception structures. In this paper, we reflect upon our experiences using the Java exception handling mechanism. Based on these experiences, we discuss two issues we believe underlie the difficulties encountered: exceptions are a global design problem, and exception sources are often difficult to predict in advance. We then describe a design approach, based on work by Litke for Ada programs, which we have used to simplify exception structure in existing Java programs.

<p>One of the most dominant philosophies within programming disciplines is the philosophy of layered systems. In a layered system (or hierarchical system) the layers are thought of as each implementing an abstract machine on top of the lower layers. Such an abstract machine in turn implements utilities (e.g. data-structures and operations) to be used at higher layers.</p><p>This paper will focus on exception handling in block-structured systems (as a special case of layered systems). It will be argued that none of the existing programming language proposals for exception handling support secure and well-behaved termination of activities in a block-structured system. Moreover, it is argued that certain termination strategies within block-structured systems cannot be implemented using the existing proposals. As a result of this discussion and as a solution to the problems, a hierarchical, co-operative exception handling mechanism is proposed.</p>

For programs to be reliable and fault tolerant, each program module must be defined to behave reasonably under a wide variety of circumstances. An exception handling mechanism supports the construction of such modules. This paper descnbes an exception handling mechanism developed as part of the CLU programming language. The CLU mechanism is based on a simple model of exception handling that leads to well-structured programs. It is engineered for ease of use and enhanced program readability. This paper discusses the various models of exception handUlng, the syntax and semantics of the CLU mechanism, and methods of implementing the mechanism and integrating it in debugging and production environments.

This review paper analyses the implementation of Robotic Process Automation (RPA) in financial account reconciliations, integrating existing literature with a practical case study of a multinational life sciences firm that realized an 85% decrease in reconciliation duration. Although RPA has gained traction in enhancing repetitious financial processes, current research frequently lacks empirical specificity, sector-related constraints, and evaluations of post-implementation effects. This report identifies deficiencies in exception handling, scalability, and ERP system integration by comparing five academic and industrial sources with practical insights from the case study. A thorough RPA Reconciliation Framework is proposed, including process discovery, bot logic, error feedback, AI integration, compliance, and change management. The results underscore RPA's capacity to enhance speed, precision, and auditability, while indicating that future research should concentrate on hybrid RPA-AI systems and uniform maturity models.

Multi-core processors are present in everyone's daily life. Consequently, concurrent programming has reemerged as a pressing concern for everyone interested in exploring all the potential computational power in these machines. But, the emergence of new concurrency models and programming languages also brings new challenges in terms of how one can deal with abnormal occurrences, much due to the heterogenous parallel control flow. Unexpectedly, sequential Exception Handling models remain as the most used tool for robustness, even in the most recent concurrent programming languages. Though, the appearance of more complex models, such as programming languages with implicit concurrency, might pose a challenge too big for these sequential mechanisms. In this article we will provide evidences why such models are not generally suited to deal with faults in programs with implicit concurrency and, in the light of more recent advances in concurrent Exception Handling, we will discuss the attributes of a model for addressing this problem.

Decompilation is a reconstruction of a program in a high-level language from a program in a low-level language. Typical applications of decompilation are software security assessment, malware analysis, error correction and reverse engineering for interoperability. Native code decompilation is traditionally considered in the context of the C programming language. C++ presents new challenges for decompilation, since the rules of translation from C++ to assembly language are far more complex than those of C. In addition, when decompiling a program that was originally written in C++, reconstruction of C++ specific constructs is desired. In this paper we discuss new methods that allow partial recovery of C++ specific language constructs from a low-level code provided that this code was obtained from a C++ compiler. The challenges that arise when decompiling such code are described. These challenges include reconstruction of polymorphic classes, class hierarchies, member functions and exception handling constructs. An approach to decompilation that is used to overcome these challenges is presented. Smart Dec, a native code to C++ decompiler that is being developed by the authors at Select LTD is presented. It reconstructs expressions, function arguments, local and global variables, integral and composite types, loops and compound conditional statements, C++ class hierarchies and exception handling constructs. An empirical study of the decompiler is provided.

Decomposing software according to the structure of the problem domain makes it easier to manage its complexity. Such a decomposition requires a programming language that supports compositions matching those in the problem domain. However, current programming languages only offer a restricted set of control-flow related composition mechanisms, such as method invocation and exception handling. This limits developers in choosing the desired decomposition. Previously, we showed that continuations are suitable for implementing various control-flow compositions. However, composing and refining these implementations requires new language features. In this paper, we outline requirements for control-flow composition and show how exception handling can be implemented using continuations, scopes and bindings.