Bruno Cabral

Exception handling: a field study in Java and .NET

Most modern programming languages rely on exceptions for dealing with abnormal situations. Although exception handling was a significant improvement over other mechanisms like checking return codes, it is far from perfect. In fact, it can be argued that this mechanism is seriously limited, if not, flawed. This paper aims to contribute to the discussion by providing quantitative measures on how programmers are currently using exception handling. We examined 32 different applications, both for Java and .NET. The major conclusion for this work is that exceptions are not being correctly used as an error recovery mechanism. Exception handlers are not specialized enough for allowing recovery and, typically, programmers just do one of the following actions: logging, user notification and application termination. To our knowledge, this is the most comprehensive study done on exception handling to date, providing a quantitative measure useful for guiding the development of new error handling mechanisms.

Choosing the right NoSQL database for the job: a quality attribute evaluation

For over forty years, relational databases have been the leading model for data storage, retrieval and management. However, due to increasing needs for scalability and performance, alternative systems have emerged, namely NoSQL technology. The rising interest in NoSQL technology, as well as the growth in the number of use case scenarios, over the last few years resulted in an increasing number of evaluations and comparisons among competing NoSQL technologies. While most research work mostly focuses on performance evaluation using standard benchmarks, it is important to notice that the architecture of real world systems is not only driven by performance requirements, but has to comprehensively include many other quality attribute requirements. Software quality attributes form the basis from which software engineers and architects develop software and make design decisions. Yet, there has been no quality attribute focused survey or classification of NoSQL databases where databases are compared with regards to their suitability for quality attributes common on the design of enterprise systems. To fill this gap, and aid software engineers and architects, in this article, we survey and create a concise and up-to-date comparison of NoSQL engines, identifying their most beneficial use case scenarios from the software engineer point of view and the quality attributes that each of them is most suited to.

A transactional model for automatic exception handling

Software reliability and error handling are concepts that any programmer knows and deals with on a daily basis. Even so, studies suggest that the current approach to exception handling raises fundamental incompatibilities with object-oriented concepts, being a major cause for the lack of quality on error handling code. In this paper, we propose an exception handling model that makes the runtime environment responsible for automatically dealing with abnormal situations. The platform provides a number of benign recovery actions that are able to deal automatically with most common exception types. Whenever an exception is raised, and a benign recovery method can be found, code is re-executed from a clean transactional state. In this approach try blocks not only represent a nesting level where a fault can occur but also a block that can be re-executed transactionally as a clean slate. For validating the approach two case studies were performed. One involved providing automatic exception handling for Glassfishs Java Messaging System implementation and the other for the Hipergate CRM application. Both showed that increased robustness is possible while freeing the programmer from manually writing extensive error-handling code.

A Case for Automatic Exception Handling

Exception handling mechanisms have been around for more than 30 years. Nevertheless, modern exceptions systems are not very different from the early models. Programming languages designers often neglect the exception mechanism and look at it more like an add-on for their language instead of central part. As a consequence, software quality suffers as programmers feel that the task of writing good error handling code is too complex, unattractive and inefficient. We propose a new model that automates the handling of exceptions by the runtime platform. This model frees the programmer from having to write exception handling code and, at the same time, successfully increases the resilience of programs to abnormal situations.

ÆminiumGPU: An Intelligent Framework for GPU Programming

As a consequence of the immense computational power available in GPUs, the usage of these platforms for running data-intensive general purpose programs has been increasing. Since memory and processor architectures of CPUs and GPUs are substantially different, programs designed for each platform are also very different and often resort to a very distinct set of algorithms and data structures. Selecting between the CPU or GPU for a given program is not easy as there are variations in the hardware of the GPU, in the amount of data, and in several other performance factors.

Implementing Retry - Featuring AOP

Everyday experience tells us that some errors are transient, but also that some can be handled simply by “retrying” the failed operation. For instance, a glitch on the network might turn a resource unreachable for a short period of time; or a sudden peak of work on a server can cause a momentary denial of service. In many occasions, without other kind of specialized recovery code, it is possible to keep a program running only by retrying a failed operation. Unfortunately, retry is not explicitly available on many platforms or programming languages and, even if it were, it could not be blindly used for dealing with every abnormal situation. On languages like C# or Java, or even on languages that offer the retry construct such as Smalltalk and Eiffel, where errors are represented and communicated through exceptions, there is no simple way to clear the effects of a failed operation and, thus, re-attempt its execution. Programmers have to explicitly write sometimes complex and error-prone code to repair the state of a program and the execution context. In this paper, we propose an AOP technique for implementing “retry” on systems lacking such a feature without using any language extensions for AOP or imposing modifications to the development language. Our approach eliminates the need for programmers to write “state-cleaning” code for normal objects by means of a transparent transactional mechanism and provides the means to identify non-idempotent operations on the code. In our evaluation we show that a relevant number of application failures can be masked using this approach.

Prototyping a GPGPU Neural Network for Deep-Learning Big Data Analysis ☆

Abstract Big Data concerns with large-volume complex growing data. Given the fast development of data storage and network, organizations are collecting large ever-growing datasets that can have useful information. In order to extract information from these datasets within useful time, it is important to use distributed and parallel algorithms. One common usage of big data is machine learning, in which collected data is used to predict future behavior. Deep-Learning using Artificial Neural Networks is one of the popular methods for extracting information from complex datasets. Deep-learning is capable of more creating complex models than traditional probabilistic machine learning techniques. This work presents a step-by-step guide on how to prototype a Deep-Learning application that executes both on GPU and CPU clusters. Python and Redis are the core supporting tools of this guide. This tutorial will allow the reader to understand the basics of building a distributed high performance GPU application in a few hours. Since we do not depend on any deep-learning application or framework—we use low-level building blocks—this tutorial can be adjusted for any other parallel algorithm the reader might want to prototype on Big Data. Finally, we will discuss how to move from a prototype to a fully blown production application.

Automatic Parallelization: Executing Sequential Programs on a Task-Based Parallel Runtime

There are billions of lines of sequential code inside nowadays’ software which do not benefit from the parallelism available in modern multicore architectures. Automatically parallelizing sequential code, to promote an efficient use of the available parallelism, has been a research goal for some time now. This work proposes a new approach for achieving such goal. We created a new parallelizing compiler that analyses the read and write instructions, and control-flow modifications in programs to identify a set of dependencies between the instructions in the program. Afterwards, the compiler, based on the generated dependencies graph, rewrites and organizes the program in a task-oriented structure. Parallel tasks are composed by instructions that cannot be executed in parallel. A work-stealing-based parallel runtime is responsible for scheduling and managing the granularity of the generated tasks. Furthermore, a compile-time granularity control mechanism also avoids creating unnecessary data-structures. This work focuses on the Java language, but the techniques are general enough to be applied to other programming languages. We have evaluated our approach on 8 benchmark programs against OoOJava, achieving higher speedups. In some cases, values were close to those of a manual parallelization. The resulting parallel code also has the advantage of being readable and easily configured to improve further its performance manually.

NoSQL Databases: A Software Engineering Perspective

For over forty years, relational databases have been the leading model for data storage, retrieval and management. However, due to increasing needs for scalability and performance, alternative systems have started being developed, namely NoSQL technology. With increased interest in NoSQL technology, as well as more use case scenarios, over the last few years these databases have been more frequently evaluated and compared. It is necessary to find if all the possibilities and characteristics of non-relational technology have been disclosed. While most papers perform mostly performance evaluation using standard benchmarks, it is nevertheless important to notice that real world scenarios, with real enterprise data, do not function solely based on performance. In this paper, we have gathered a concise and up-to-date comparison of NoSQL engines, their most beneficial use case scenarios from the software engineer viewpoint, their advantages and drawbacks by surveying the currently available literature.

Hidden truth behind .NET's exception handling today

The emergence of exception handling (EH) mechanisms in modern programming languages made available a different way of communicating errors between procedures. For years, programmers trusted in correct documentation of error codes returned by procedures to correctly handle erroneous situations. Now, they have to focus on the documentation of exceptions for the same effect. But to what extent can exception documentation be trusted? Moreover, is there enough documentation for exceptions? And in what way do these questions relate to the discussion on checked against unchecked exceptions? For a given set of Microsoft .NET applications, code and documentation were thoroughly parsed and compared. This showed that exception documentation tends to be scarce. In particular, it showed that 90% of exceptions are undocumented. Furthermore, programmers were demonstrated to be keener to document exceptions they explicitly throw while typically leaving exceptions resulting from method calls undocumented. This conclusion lead to another question: how do programmers use the EH mechanisms available in modern programming languages? More than 16 different .NET applications were examined in order to provide an answer. The major conclusion of this work is that exceptions are not being correctly used as an error-handling mechanism. These results contribute to the assessment of the effectiveness of the unchecked exceptions approach.