Search

Several contemporary programming languages, including Java, have exception management as a crucial built-in feature. By employing try-catch blocks, it enables developers to handle unusual or unexpected conditions that might arise at runtime beforehand. If exception management is neglected or applied improperly, it may result in serious incidents like equipment failure. Exception handling mechanisms are difficult to implement and time expensive with the preceding methodologies. This research introduces an efficient Long Short Term Memory (LSTM) technique for handling the exceptions automatically, which can identify the locations of the try blocks and automatically create the catch blocks. Bulky java code is collected from GitHub and splitted into several different fragments. For localization of the try block, Bidirectional LSTM (BiLSTM) is used initially as a token level encoder and then as a statement-level encoder. Then, the Support Vector Machine (SVM) is used to predict the try block present in the given source code. For generating a catch block, BiLSTM is initially used as an encoder, and LSTM is used as a decoder. Then, SVM is used here to predict the noisy tokens. The loss functions of this encoder-decoder model have been trained to be as small as possible. The trained model then uses the black widow method to forecast the following tokens one by one and then generates the entire catch block. The proposed work reaches 85% accuracy for try block localization and 50% accuracy for catch block generation. An improved LSTM with an attention mechanism method produces an optimal solution compared to the existing techniques. Thus the proposed method is the best choice for handling the exceptions. [ABSTRACT FROM AUTHOR]

The Java virtual machine (JVM) is the cornerstone of the Java platforms. A JVM's exception handling implementation interrupts, when the objective application encounters an exception (or an error), the normal execution of the application and performs specific handling tasks. However, little research has been done in systematically validating JVMs' exception handling implementations—test programs or even applications need to be carefully designed for throwing/catching exceptions at runtime; a JVM's exception handling implementation is also complicated, making it challenging to design tests for testing all of its functionalities. Inspired by the recent success of fuzz testing of compilers and JVM implementations, we introduce EHCBuilder, the first technique for fuzzing JVMs' exception handling implementations. The key idea is to construct exception handling chains, each of which abstracts a program's execution into a sequence of exception throwings, catchings, and/or handlings. A classfile seed can then be mutated into test programs with diverse exception handling chains, enabling (1) exceptions to be continuously thrown and caught at runtime, and (2) JVMs' exception handling implementations to be much more thoroughly tested. We have implemented EHCBuilder and evaluated EHCBuilder on popular JVM implementations including OpenJDK's HotSpot, Eclipse's OpenJ9, Azul's Zulu, and Oracle's GraalVM. Our results show that EHCBuilder can generate programs with very intricate exception handling chains and reveal differences among JVMs' exception handling implementations: Up to thousands of lines of source code in HotSpot's exception handling implementation are covered more than the original benchmarks; during 39 K iterations, EHCBuilder generates exception handling chains of different lengths, revealing 258 runtime differences. We classify the differences into four categories, and reveal a fast throw issue confirmed by HotSpot developers and another initCause issue confirmed by the OpenJ9 community. [ABSTRACT FROM AUTHOR]

Copyright of Journal of Frontiers of Computer Science & Technology is the property of Beijing Journal of Computer Engineering & Applications Journal Co Ltd. and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use. This abstract may be abridged. No warranty is given about the accuracy of the copy. Users should refer to the original published version of the material for the full abstract. (Copyright applies to all Abstracts.)

Recently, Python is the most-widely used language in artificial intelligence (AI) projects requiring huge amount of CPU and memory resources, and long execution time for training. For saving the project duration and making AI software systems more reliable, it is inevitable to handle exceptions appropriately at the code level. However, handling exceptions highly relies on developer's experience. This is because, as an interpreter-based programming language, it does not force a developer to catch exceptions during development. In order to resolve this issue, we propose an approach to suggesting appropriate exceptions for the AI code segments during development after training exceptions from the existing handling statements in the AI projects. This approach learns the appropriate token units for the exception code and pretrains the embedding model to capture the semantic features of the code. Additionally, the attention mechanism learns to catch the salient features of the exception code. For evaluating our approach, we collected 32,771 AI projects using two popular AI frameworks (i.e. Pytorch and Tensorflow) and we obtained the 0.94 of Area under the Precision-Recall Curve (AUPRC) on average. Experimental results show that the proposed method can support the developer's exception handling with better exception proposal performance than the compared models. [ABSTRACT FROM AUTHOR]

Software agents are normally expected to operate in open and dynamic environments, and therefore they are often supposed to face situations that significantly deviate from the nominal course of events. The effective management of exceptional situations is of paramount importance to provide agents with the needed means to operate in their environments, mostly because these situations should be considered as the norm in open and dynamic environments. This paper presents some recent additions to the Jadescript agent-oriented programming language that were specifically designed to provide agents with the needed capabilities to effectively detect and manage exceptional situations. The first part of this paper motivates the need of sophisticated exception handling capabilities, also by relating the proposed language features with the state of the art documented in the literature. Then, the second part of this paper discusses the proposed language features, also considering the conceptual similarities and differences with the related features normally available in mainstream programming languages. In particular, the proposed language features are presented in terms of three language improvements: the general-purpose support to handle exceptions, the specific support to handle behaviour failures, and the specific support to handle stale messages. Finally, before concluding with some indications on future research activities, the third part of this paper describes a concrete example intended to practically present the actual use of the new language features. [ABSTRACT FROM AUTHOR]

In order to achieve their business goals, organizations heavily rely on the operational excellence of their business processes. In traditional scenarios, business processes are usually well-structured, clearly specifying when and how certain tasks have to be executed. Flexible and knowledge-intensive processes are gathering momentum, where a knowledge worker drives the execution of a process case and determines the exact process path at runtime. In the case of an exception, the knowledge worker decides on an appropriate handling. While there is initial work on exception handling in well-structured business processes, exceptions in case management have not been sufficiently researched. This paper proposes an exception handling framework for stage-oriented case management languages, namely Guard Stage Milestone Model, Case Management Model and Notation, and Fragment-based Case Management. The effectiveness of the framework is evaluated with two real-world use cases showing that it covers all relevant exceptions and proposed handling strategies. [ABSTRACT FROM AUTHOR]

Exception handling has been successfully proposed in software engineering practice as a simple, but effective, technology to address abnormal situations possibly occurring at runtime. Such mechanisms support the robust composition of heterogeneous software components, promoting code modularity, decoupling, and separation of concerns. Multi-agent systems bring these features to an extreme, but often lack systematic mechanisms for treating exceptions as part of their design. In this paper, we show how exception handling mechanism can be introduced in SARL, leveraging the abstractions that characterize its programming model. We introduce a new kind of space, supporting the responsibility distribution among agents concerning the handling of exceptional situations. [ABSTRACT FROM AUTHOR]

Abstract Exception handling is a well-known technique used to improve software robustness. However, recent studies report that developers typically neglect exception handling (mostly novice ones). We believe the quality of exception handling code in a software project is directly affected (i) by the absence, or lack of awareness, of an explicit exception handling policy and guidelines and (ii) by a silent rising of exception handling anti-patterns. In this paper, we investigate this phenomenon in a case study of a long-lived large-scale Java Web system in a Public Education Institution, trying to better understand the relationship between (i) and (ii), and the impact of developers’ turnover, skills, and guidance in (ii). Our case study takes into account the technical and human aspects. As a first step, we surveyed 21 developers regarding their perception of exception handling in the system’s institution. Next, we analysed the evolution of exception handling anti-patterns across 15 releases of the target system. We conducted a semi-structured interview with three senior software engineers, representatives of the development team, to present partial results of the case and raise possible causes for the found problems. The interviewed professionals and a second analysis of the code identified the high team turnover as the source of this phenomenon, since the public procurement process for hiring new developers has mostly attracted novice ones. These findings suggest that the absence of an explicit exception handling policy impacts negatively in the developers’ perception and implementation of exception handling. Furthermore, the absence of such policy has been leading developers to replicate existing anti-patterns and spread them through new features added during system evolution. We also observed that most developers have low skills regarding exception handling in general and low knowledge regarding the design and implementation of exception handling in the system. The system maintainer now has a diagnosis of the major causes of the quality problems in the exception handling code and was able to lead the required measures to repair this technical debt.

A structured programming language does not or should not have an unconditional jump goto statement. Any program that contains a goto is not structured. There had been a serious discussion over the years whether or not goto statements should be eliminated or kept, and there was one of the most discussed papers that spoke for the elimination of goto statements. However, there were still some that spoke for keeping the goto statements, even only for certain cases. The modeling language PROMELA is one of some languages that contain goto - the language creator agreed to keep goto. This study proposes an automatic translation of goto that appears in a PROMELA model into Java program using exception handling in Java. The automatic translation is part of the translator from PROMELA model into Java program done in the previous study. There are at least two reasons why used exception handling: (1) it is able to bring program's execution path jumping from one part of program to another. This jump can be addressed to the specified target by exploiting type of exception being captured. (2) it can be assigned with a value - usually as a message about the exception. So that, by assigning different value will distinguish one goto from others in case there were more than one gotos in the same block of codes. At the end, a program was written to show the automatic translation works properly. However, because of the behavior of goto itself and limitations of exception handling in Java, the automatic translation developed in this study has not handled all types of goto patterns appeared in PROMELA model. The result of this study were the automatic translation correspond to three types of goto pattern in a PROMELA model, and a procedure to determine the right type of goto pattern correspond to the automatic translation. The testing was conducted by running the program of automatic translation written in Java using 30 cases (PROMELA model containing the goto pattern), 10 for each. In accordance with the testing, the automatic translation worked properly for all cases. [ABSTRACT FROM AUTHOR]

Service oriented architecture (SOA) provides a flexible platform to build collaborative Internet applications by composing existing self-contained and autonomous services. However, the implicit interactions among the concurrently provisioned services may introduce interference to Internet applications and cause them behave abnormally. It is thus desirable to isolate services to safeguard their application consistency. Existing approaches mostly address this problem by restricting concurrent execution of services to avoid all the implicit interactions. These approaches, however, compromise the performance and flexibility of Internet applications due to the long running nature of services. This paper presents Sifter, a new service isolation strategy for Internet applications. We devise in this strategy a novel static approach to analyze the potential implicit interactions among the services and their impacts on the consistency of the associated Internet applications. By locating only those afflicted implicit interactions that may violate the application consistency, a novel approach based on exception handling and behavior constraints is customized to involved services to eliminate their impacts. We show that this approach exempts the consistency property of Internet applications from being interfered at runtime. The experimental results show that our approach has a better performance than existing solutions. [ABSTRACT FROM AUTHOR]

Automation is considered as the basis for the introduction of the fourth industrial revolution in ports and for the implementation of a number of innovations. Often the actual results of container terminal automation do not match the expectations of terminal operators. Through the application of scientific methods of investigation - monitoring, comparative analysis, analysis and synthesis of existing publications on the subject - some problematic issues have been established, such as the lack of common standards, pressure by trade unions, processing of exceptions, etc., calling into question the implementation of any good automated terminal project. The synergistic approach in the modeling, construction and exploitation of automated container terminals leads to the conclusion that, on one hand, a solution to the above issues should be sought in the cooperation between all port stakeholders (automation system manufacturers, software developers, terminal and logistics operators, carriers). On the other hand, the competitiveness of automated container terminals depends on the skills of the port specialists. They must be prepared for the monitoring, analysis and management of automated systems, they must be adequately qualified for the integration of systems and for the processing of exceptions, they must be able to foresee the consequences of each of their actions for the whole system. [ABSTRACT FROM AUTHOR]

Abstract The ever-increasing popularity of mobile devices (e.g., mobile phones and smart watches) has created a variety of crowdsourcing applications by employing the massive and distributed mobile computing resources. Typically, a task requester sends his/her task request and constraint conditions to a crowdsourcing platform, and then the crowdsourcing platform is responsible for finding a set of appropriate workers (e.g., mobile users) from massive candidates to satisfy the task request. However, for a mobile crowdsourcing task being executed by a set of workers, a pre-selected worker may become unavailable due to various exceptions. In this situation, it is significant for the crowdsourcing platform to quickly find another similar worker to replace the unavailable worker so as to smooth the crowdsourcing process. However, the above exception handling process is often challenging as candidate workers are often not willing to release their sensitive information to the platform due to privacy concerns. In view of this challenge, in this paper, a novel privacy-preserving exception handling approach, named ExH Simhash , is put forward based on Simhash technique. Finally, through a set of simulated experiments, we validate the feasibility of ExH Simhash in terms of substitution equivalence and computational time.

Service-Oriented Architectures (SOA) enable the automatic creation of business applications from independently developed and deployed Web services. As Web services are inherently a priori unknown, how to deliver reliable Web services compositions is a significant and challenging problem. Services involved in an SOA often do not operate under a single processing environment and need to communicate using different protocols over a network. Under such conditions, designing a fault management system that is both efficient and extensible is a challenging task. In this article, we propose SFSS, a self-healing framework for SOA fault management. SFSS is predicting, identifying, and solving faults in SOAs. In SFSS, we identified a set of highlevel exception handling strategies based on the QoS performances of different component services and the preferences articled by the service consumers. Multiple recovery plans are generated and evaluated according to the performance of the selected component services, and then we execute the best recovery plan. We assess the overall user dependence (i.e., the service is independent of other services) using the generated plan and the available invocation information of the component services. Due to the experiment results, the given technique enhances the service selection quality by choosing the services that have the highest score and betters the overall system performance. The experiment results indicate the applicability of SFSS and show improved performance in comparison to similar approaches. [ABSTRACT FROM AUTHOR]

ISO Prolog provides catch and throw to realize the control flow of exception handling. This pearl demonstrates that catch and throw are inconspicuously amenable to the implementation of backjumping. In fact, they have precisely the semantics required: rewinding the search to a specific point and carrying of a preserved term to that point. The utility of these properties is demonstrated through an implementation of graph coloring with backjumping and a backjumping SAT solver that applies conflict-driven clause learning. [ABSTRACT FROM AUTHOR]

Existing algorithms experience difficulty resisting additive and subtractive attacks because the embedded watermarks are independent of the carrier programs. A dynamic software watermarking algorithm based on exception handling is proposed in this paper. The algorithm considers the fact that exception handling, which is difficult to remove, commonly exists in the programs to ensure the normal program operation. First, an exception type table is constructed, and the binary watermark to be embedded is mapped to a sequence of exception types by scrambling encoding. Second, corresponding trigger conditions and exception handlers are constructed, and watermark embeddable points are acquired in execution paths under secret inputs. Finally, the code segment of the constructed trigger conditions and exception handlers are inserted into the program with several meticulously designed identifiers. For watermark extraction, the triggered exception types can be obtained with the identifiers by executing the watermarked executable program under secret inputs. The mapping relationship between the exception type and watermark is utilized to decode the binary watermark. The algorithm analysis and experimental results show that the proposed algorithm can embed a watermark in the source code and extract it in an executable program. The algorithm demonstrates good performance against additive and subtractive attacks.

Exception handling is a well-known technique used to improve software robustness. However, recent studies report that developers typically neglect exception handling (mostly novice ones). We believe the quality of exception handling code in a software project is directly affected (i) by the absence, or lack of awareness, of an explicit exception handling policy and guidelines and (ii) by a silent rising of exception handling anti-patterns. In this paper, we investigate this phenomenon in a case study of a long-lived large-scale Java Web system in a Public Education Institution, trying to better understand the relationship between (i) and (ii), and the impact of developers' turnover, skills, and guidance in (ii). Our case study takes into account the technical and human aspects. As a first step, we surveyed 21 developers regarding their perception of exception handling in the system's institution. Next, we analysed the evolution of exception handling anti-patterns across 15 releases of the target system. We conducted a semi-structured interview with three senior software engineers, representatives of the development team, to present partial results of the case and raise possible causes for the found problems. The interviewed professionals and a second analysis of the code identified the high team turnover as the source of this phenomenon, since the public procurement process for hiring new developers has mostly attracted novice ones. These findings suggest that the absence of an explicit exception handling policy impacts negatively in the developers' perception and implementation of exception handling. Furthermore, the absence of such policy has been leading developers to replicate existing anti-patterns and spread them through new features added during system evolution. We also observed that most developers have low skills regarding exception handling in general and low knowledge regarding the design and implementation of exception handling in the system. The system maintainer now has a diagnosis of the major causes of the quality problems in the exception handling code and was able to lead the required measures to repair this technical debt. [ABSTRACT FROM AUTHOR]

To programs running on components in a distributed system, both network and component failures manifest as connection faults that are represented by exceptions. Although many strategies are available for handling connection faults, it is often necessary to compose multiple strategies in such programs, especially in Internet of Things systems and cyber-physical systems. Moreover, it should be possible to specify a program's connection fault handling behaviors prior to implementation. Having observed the lack of appropriate design-level constructs, we propose an extended AND/OR graph for modeling composite connection fault handling behaviors in programs. The extended AND/OR graph enables succinct representations of complex fault handling behaviors by composing the constituent strategies of retrying, communicating failure, and ignoring failure. Furthermore, we develop a model-based testing framework that accepts the extended AND/OR graph specification as input and generates tests for checking the connection fault handling behaviors of a program constructed from the specification. The proposed method is illustrated with a Java program to detect and report failure of a device. In particular, the AND/OR graph specification stipulates that the program handles connection faults covering network failures by composing retrying strategy. From this specification, tests are generated by finding all solution trees of the AND/OR graph subject to the number of retries to cover all the paths that lead to the program's normal and exceptional exits, respectively. The extended AND/OR graph and the model-based testing framework contribute to the means for specifying and testing connection fault handling behaviors of programs that are crucial to the success of Internet of Things systems and cyber-physical systems. [ABSTRACT FROM AUTHOR]

During a manufacturing operation, exceptions may occur dynamically and unpredictably. Their occurrence may lead to the degradation of system performance or, in the worst case scenario may interrupt the production process by causing errors in the schedule plan. This paper classifies three families of exceptions: (1) out-of-order events such as machine breakdowns, (2) operational out-of-ordinary events such as rush orders and (3) deteriorations of manufacturing resource performance such as reductions of machines’ utilization. In all cases, in order to maintain an adequate level of system performance, it is necessary to detect exceptions, to diagnose them quickly and to recover them by taking corrective actions to avoid fault propagations. Decisions concerning how to deal with exceptions, i.e. which strategy to implement, depend on the manufacturing environment (dedicated line, flexible system, reconfigurable system or a mix of them) and the advantages arising from using a certain exception handling policy vary from one production system to another. The activity of reconfiguring manufacturing resources has been demonstrated to be a powerful operation strategy to handle machine breakdowns. This paper extends the concept of ‘reconfiguration for exception handling’ to other families of exceptions and proposes reconfiguration for their recovery. The reconfiguration process is handled by an agent-based control system that implements four negotiation processes among manufacturing resource agents. [ABSTRACT FROM AUTHOR]