Background. A smart contract is a computer program enclosing the terms of a legal agreement between two or more parties which is automatically verified and executed via a computer network called blockchain. Once a smart contract transaction is completed the blockchain is updated and the transaction cannot be changed anymore. This implies that any error codified in the smart contract program cannot be rectified. Therefore, it is of vital importance that developers of smart contracts properly exploit error handling to prevent issues during and after the contract execution. Existing programming languages for smart contracts, support developers in this task by providing a set of Error Handling (EH) features. However, it is unclear the extent to which developers effectively use EH in practice. Aims. Our work aims to fill this gap by empirically investigating the state of practice on the adoption of EH features of one of the most popular programming languages for smart contracts, namely Solidity. Method. We empirically analyse the usage of EH features in 283K unique open-source Solidity smart contracts for the Ethereum blockchain. Results. Our analysis of the documentation of the different versions of Solidity coupled with the empirical evaluation of the EH uses and misuses found in real-word smart contracts, indicate that, among other things, Solidity EH features have been changing frequently across versions, and that the adoption of most of the Solidity EH features has been limited in practice. However, we observe an upward trend in the usage of the require EH feature, which is specifically designed for smart contract development. Conclusions. The insights from our study could help developers improve their EH practice as well as designers of smart contract programming languages to equip their language with appropriate EH features.

Despite the substantial progress in compiler testing, research endeavors have mainly focused on detecting compiler crashes and subtle miscompilations caused by bugs in the implementation of compiler optimizations. Surprisingly, this growing body of work neglects other compiler components, most notably the front-end. In statically-typed programming languages with rich and expressive type systems and modern features, such as type inference or a mix of object-oriented with functional programming features, the process of static typing in compiler front-ends is complicated by a high-density of bugs. Such bugs can lead to the acceptance of incorrect programs (breaking code portability or the type system's soundness), the rejection of correct (e.g. well-typed) programs, and the reporting of misleading errors and warnings. We conduct, what is to the best of our knowledge, the first empirical study for understanding and characterizing typing-related compiler bugs. To do so, we manually study 320 typing-related bugs (along with their fixes and test cases) that are randomly sampled from four mainstream JVM languages, namely Java, Scala, Kotlin, and Groovy. We evaluate each bug in terms of several aspects, including their symptom, root cause, bug fix's size, and the characteristics of the bug-revealing test cases. Some representative observations indicate that: (1) more than half of the typing-related bugs manifest as unexpected compile-time errors: the buggy compiler wrongly rejects semantically correct programs, (2) the majority of typing-related bugs lie in the implementations of the underlying type systems and in other core components related to operations on types, (3) parametric polymorphism is the most pervasive feature in the corresponding test cases, (4) one third of typing-related bugs are triggered by non-compilable programs. We believe that our study opens up a new research direction by driving future researchers to build appropriate methods and techniques for a more holistic testing of compilers.

The evolution of software bugs has been a well-studied topic in software engineering. We used three different program analysis tools to examine the different versions of two popular sets of programming tools (gnu Binary and Core utilities), and check if their bugs increase or decrease over time. Each tool is based on a different approach, namely: static analysis, symbolic execution, and fuzzing. In this way we can observe potential differences on the kinds of bugs that each tool detects and examine their effectiveness. To do so, we have performed a qualitative analysis on the results. Overall, our results indicate that we cannot say if bugs either decrease or increase over time and that the tools identify different bug types based on the method they follow.