Data-oriented exception handling

Exception handling mechanisms were added to programming languages to segregate normal algorithmic processing from error processing. However, handlers which are typically associated with exceptions through a program's control features, clutter source text when features are nested or when different objects require different responses to exceptions. The authors describe a method for associating handlers with data objects in declarations that better segregates algorithmic and error processing. They call their notion data-oriented exception handling to distinguish it from more conventional, control-oriented mechanisms. Empirical studies of Ada programs indicate that conventional exception handling mechanisms are more complex than necessary and that data-oriented exception handling can be used to produce programs that are smaller, better structured, and easier to understand and modify     

Advanced exception handling mechanisms

It is no longer possible to consider exception handling as a secondary issue in language design, or even worse, a mechanism added after the fact via a library approach. Exception handling is a primary feature in language design and must be integrated with other major features, including advanced control flow, objects, coroutines, concurrency, real-time, and polymorphism. Integration is crucial as there are both obvious and subtle interactions between exception handling and other language features. Unfortunately, many exception handling mechanisms work only with a subset of the features and in the sequential domain. A framework for a comprehensive, easy to use, and extensible exception handling mechanism is presented for a concurrent, object-oriented environment. The environment includes language constructs with separate execution stacks, e.g. coroutines and tasks, so the exception environment is significantly more complex than the normal single-stack situation. The pros and cons of various exception features are examined, along with feature interaction with other language mechanisms. Both exception termination and resumption models are examined in this environment, and previous criticisms of the resumption model, a feature commonly missing in modern languages, are addressed     

As-if-serial exception handling semantics for Java futures

Exception handling enables programmers to specify the behavior of a program when an exceptional event occurs at runtime. Exception handling, thus, facilitates software fault tolerance and the production of reliable and robust software systems. With the recent emergence of multi-processor systems and parallel programming constructs, techniques are needed that provide exception handling support in these environments that are intuitive and easy to use. Unfortunately, extant semantics of exception handling for concurrent settings is significantly more complex to reason about than their serial counterparts.In this paper, we investigate a similarly intuitive semantics for exception handling for the future parallel programming construct in Java. Futures are used by programmers to identify potentially asynchronous computations and to introduce parallelism into sequential programs. The intent of futures is to provide some performance benefits through the use of method-level concurrency while maintaining as-if-serial semantics that novice programmers can easily understand — the semantics of a program with futures is the same as that for an equivalent serial version of the program. We extend this model to provide as-if-serial exception handling semantics. Using this model our runtime delivers exceptions to the same point it would deliver them if the program was executed sequentially. We present the design and implementation of our approach and evaluate its efficiency using an open source Java virtual machine.     

An exception handling framework for case management

Software and Systems Modeling - In order to achieve their business goals, organizations heavily rely on the operational excellence of their business processes. In traditional scenarios, business...     

Toward modular verifiable exception handling

Recognizing that an error condition is an intrinsic part of the abstract type to which the operation that detects the condition belongs, an attempt is made to specify and implement error condition detection and handling within the framework of the Alphard form, a construct for encapsulation of data type specification and implementation. The essence of the problem is this: while error condition detection is done by the operation in the form, only the user of the type can determine the meaning of the condition with respect to the way the type is used. Thus, the user must be able to specify the handler. Unfortunately, programming the handler often requires access to encapsulated implementation details which are hidden from the user.After discussing the general issues of exception handling, modularity, and abstract data types, this paper proposes a solution for one category of exceptions, namely errors. Specifically an externally visible condition name is the link between an error's occurrence and some externally visible but internally programmed handler for it. Issues raised by this partial solution, including those of proof rules, are discussed.     

一种异常处理机制的设计与实现

异常处理是一种用来检测异常并时其进行处理的技术。异常处理机制已作为现代程序设计语言的一个重要的特性被广泛地采纳,以增强系统运行的可靠性,提高软件的健壮性。对异常处理在程序语言的实现进行了一般性研究,分析比较几种异常处理机制及其实现方法,提出了一种新的异常处理机制的实现方法。     

实时嵌入式容错系统的关键技术研究

简要回顾了容错技术的发展过程并分析了不同故障模型下系统的客错方式.对于瞬时故障、间歇性故障的容错可采用软件冗余方法,在实时嵌入式系统中采用软件容错时必须考虑任务的可调度性;而永久性故障则采用硬件冗余方法来解决.在此基础上,描述了一种实时双机嵌入式容错系统的模型,研究了构建容错系统需要解决的双机同步、故障检测及仲裁切换等关键问题和相应的解决方法.     

A mechanism for exception handling and its verification rules

This paper presents a control structure designed for an exception handling mechanism based on Goodenough's proposal. The aim is to provide a recovery mechanism as a basic component of any procedure-oriented language, which can handle any kind of error, ranging from design errors to occasional malfunctioning of hardware components.The semantics of the structure is described formally by means of Hoare type verification rules.     

测试Java异常处理机制的方法

异常处理机制能增强程序运行的可靠性,提高软件的健壮性.然而,如果异常处理机制使用不当,会带来许多潜在的错误,因而很有必要对程序的异常处理结构进行测试.提出了一种识别被测程序中的所有异常变量"定义-使用"关系的方法,并使用一个异常的定义-捕获度量来计算异常定义-使用链的测试覆盖.最后设计了一种异常分析及测试的原型工具.     

Static analysis of exception handling in Ada

Since the signature of an Ada subprogram does not specify the set of exceptions that the subprogram can propagate, computing the set of exceptions that a subprogram may encounter is not a trivial task. This is a source of error in large Ada systems: for example, a subprogram may not be prepared to handle an exception propagated from another subprogram several layers lower in the call-tree. In a large system, the number of paths in exceptional processing is so great that it is unlikely that testing will uncover all errors in inter-procedural exception handling. Nor are compilers or code inspections likely to locate all such errors. Exception handling is an area where static analysis has a high potential payoff for systems with high reliability requirements. We discuss fundamental notions in computing exception propagation and describe an analysis tool that has proved to be effective in detecting inconsistencies in the exception-handling code of Ada applications.     

组合服务事务的异常处理机制研究

服务组合目前已成为业界研究的热点,它为组织问应用集成提供了一种新的解决方案.在完全开放的Internet环境中,组合服务需要Web服务事务处理机制来保证其可靠性,而Web服务事务处理需要一种异常处理机制的支持.针对节点故障引起的异常给出多种异常处理策略,对其进行形式化描述,并给出了异常处理的算法.最后在此基础上提出一个可定制补偿操作及相关补偿规则的灵活的组合服务事务异常处理模型,并对其实现.     

Self-adapting recovery nets for policy-driven exception handling in business processes

In this paper, we propose Self-Adapting Recovery Net (SARN), an extended Petri net model, for specifying exceptional behavior in business processes. SARN adapts the structure of the underlying Petri net at run time to handle exceptions while keeping the Petri net design easy. The proposed framework caters for the specification of high-level recovery policies that are incorporated either with a single task or a set of tasks, called a Recovery Region. These recovery policies are generic directives that model exceptions at design time together with a set of primitive operations used at run time to handle the occurrence of exceptions. We identified a set of recovery policies that are useful and commonly needed in many practical situations. A tool has been developed to illustrate the viability of the proposed exception handling technique. B. Medjahed’s work is supported by a grant from the University of Michigan’s OVPR.     

Architecture description languages for high-integrity real-time systems

Safety-critical systems, such as those in the avionics, automotive, power, space, and medical industries, are predominantly driven by real-time embedded software and are often referred to as high-integrity real-time systems (HIRTS). In these systems, safety is of paramount importance. Safety is broadly defined as freedom from accidents and loss. When no safe alternative to normal service exists, a system must be dependable to be safe, that is, it must have reliable ways to deliver a certain quality of service. Our collaborations with industrial partners have focused on HIRTS modeling techniques. Initially, we explored the potential benefits that the most successful software architecture and modeling approaches could bring to the safety-critical domain. We subsequently designed the architecture information modeling language. AIM lets us exploit the available technologies from the same platform and thus provide stronger support for the safety case. A safety case, a key element in HIRTS certification, typically consists of a high-level argument and supporting evidence. The HLA sets the principles on which the design is based and reasons why the design should satisfy the safety requirements.     

Extending conventional languages by distributed/concurrent exception resolution

The state of art in handling and resolving concurrent exceptions is discussed and a brief outline of all research in this area is given. Our intention is to demonstrate that exception resolution is a very useful concept which facilitates joint forward error recovery in concurrent and distributed systems. To do this, several new arguments are considered. We understand resolution as reaching an agreement among cooperating participants of an atomic action. It is provided by the underlying system to make it unified and less error prone, which is important for forward error recovery, complex by nature. We classify atomic action schemes into asynchronous and synchronous ones and discuss exception handling for schemes of both kinds. The paper also deals with introducing atomic action schemes based on exception resolution into existing concurrent and distributed languages, which usually have only local exceptions. We outline the basic approach and demonstrate its applicability by showing how exception resolution can be used in Ada 83, Ada 95 (for both concurrent and distributed systems) and Java. A discussion of ways to make this concept more object-oriented and, with the help of reflection, more flexible and useful, concludes the paper.     

The exception handling effectiveness of POSIX operating systems

Operating systems form a foundation for robust application software, making it important to understand how effective they are at handling exceptional conditions. The Ballista testing system was used to characterize the handling of exceptional input parameter values for up to 233 POSIX functions and system calls on each of 15 widely used operating system (OS) implementations. This identified ways to crash systems with a single call, ways to cause task hangs within OS code, ways to cause abnormal task termination within OS and library code, failures to implement defined POSIX functionality, and failures to report unsuccessful operations. Overall, only 55 percent to 76 percent of the exceptional tests performed generated error codes, depending on the operating system being tested. Approximately 6 percent to 19 percent of tests failed to generate any indication of error despite exceptional inputs. Approximately 1 percent to 3 percent of tests revealed failures to implement defined POSIX functionality for unusual, but specified, situations. Between 18 percent and 33 percent of exceptional tests caused the abnormal termination of an OS system call or library function, and five systems were completely crashed by individual system calls with exceptional parameter values. The most prevalent sources of these robustness failures were illegal pointer values, numeric overflows, and end-of-file overruns