Charting The Evolution of Solidity Error Handling
Charalambos Mitropoulos, Maria Kechagia, Chrysostomos Maschas, Sotiris Ioannidis, Federica Sarro, Dimitris Mitropoulos
TL;DR
This paper investigates how Solidity error-handling features are used and how they evolve across versions and real-world contracts. It introduces SolBench, a data collection and analysis platform, to study 283K open-source Solidity contracts and 1.7M unique sources, linking usage patterns to compiler changes and documentation evolution. Key findings show a dominant reliance on require, rising adoption of try-catch after its introduction, and substantial EH misuses driven by external calls and input validation, all suggesting the need for better documentation and tooling. The work provides actionable recommendations, including enhanced examples, systematic version updates, and data-flow analyses to improve the reliability and security of smart contracts.
Abstract
The usage of error handling in Solidity smart contracts is vital because smart contracts perform transactions that should be verified. Transactions that are not carefully handled, may lead to program crashes and vulnerabilities, implying financial loss and legal consequences. While Solidity designers attempt to constantly update the language with new features, including error-handling (EH) features, it is necessary for developers to promptly absorb how to use them. We conduct a large-scale empirical study on 283K unique open-source smart contracts to identify patterns regarding the usage of Solidity EH features over time. Overall, the usage of most EH features is limited. However, we observe an upward trend (> 60%) in the usage of a Solidity-tailored EH feature, i.e., require. This indicates that designers of modern programming languages may consider making error handling more tailored to the purposes of each language. Our analysis on 102 versions of the Solidity documentation indicates the volatile nature of Solidity, as the language changes frequently, i.e., there are changes on EH features once or twice a year. Such frequent releases may confuse smart contract developers, discouraging them to carefully read the Solidity documentation, and correctly adopt EH features. Furthermore, our findings reveal that nearly 70% of the examined smart contracts are exposed to potential failures due to missing error handing, e.g., unchecked external calls. Therefore, the use of EH features should be further supported via a more informative documentation containing (1) representative and meaningful examples and (2) details about the impact of potential EH misuses.
