View in EDS

Exceptions Can Be Nested: An Exploratory Study on Nested Exceptions in Java Crashes.

Saved in:
Bibliographic Details
Title: Exceptions Can Be Nested: An Exploratory Study on Nested Exceptions in Java Crashes.
Authors: Liu, Shaoting1 (AUTHOR), Xu, Haiyan1 (AUTHOR), Xin, Qi1 (AUTHOR), Xuan, Jifeng1 (AUTHOR) jxuan@whu.edu.cn
Source: Journal of Software: Evolution & Process. Apr2026, Vol. 38 Issue 4, p1-24. 24p.
Subjects: Debugging, Fault diagnosis, Software failures, Software engineering
Abstract: Crash reports can be used to reproduce a crash scenario and to localize a fault. A nested exception report is a type of crash report with two or more exceptions, where one exception is triggered by another. The complexity of nested exception reports has primarily hindered the research progress of fault localization and crash reproduction. In this paper, we conduct an exploratory study on nested exceptions in Java programs by answering five research questions for the root cause of nested exceptions, including the data scale of nested exceptions, the concerns on nested exceptions, the correlated factors on concerns, the crash scenario of nested exceptions, and the simplification of nested exceptions. To support our study, we collect a dataset of crash reports with nested exceptions, called JCauseCrash dataset, which contains 1368 nested exception reports from 26 Java projects. Our study mainly shows five empirical results on the root cause of nested exceptions in Java programs. Our findings are listed as follows: (1) From the crash reports under evaluation, there are 1368 nested exception reports in the 26 Java projects, accounting for 30.80% of the crash reports (1368/3437); (2) programmers concern on nested exception reports more than non‐nested ones; (3) the number of comments in nested exception reports correlates with the lifecycle of crash reports; (4) a parameterized constructor with an object of Throwable and the use of throw keyword highly correlates with the number of nested exception reports; and (5) without modifying the semantics of source code, programmers can simplify complex nested exception reports by eliminating a parameterized constructor with an object of Throwable class in the line of throwing an exception. [ABSTRACT FROM AUTHOR]
Copyright of Journal of Software: Evolution & Process is the property of Wiley-Blackwell and its content may not be copied or emailed to multiple sites without the copyright holder's express written permission. Additionally, content may not be used with any artificial intelligence tools or machine learning technologies. 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.)
Database: Engineering Source
Description
Abstract:Crash reports can be used to reproduce a crash scenario and to localize a fault. A nested exception report is a type of crash report with two or more exceptions, where one exception is triggered by another. The complexity of nested exception reports has primarily hindered the research progress of fault localization and crash reproduction. In this paper, we conduct an exploratory study on nested exceptions in Java programs by answering five research questions for the root cause of nested exceptions, including the data scale of nested exceptions, the concerns on nested exceptions, the correlated factors on concerns, the crash scenario of nested exceptions, and the simplification of nested exceptions. To support our study, we collect a dataset of crash reports with nested exceptions, called JCauseCrash dataset, which contains 1368 nested exception reports from 26 Java projects. Our study mainly shows five empirical results on the root cause of nested exceptions in Java programs. Our findings are listed as follows: (1) From the crash reports under evaluation, there are 1368 nested exception reports in the 26 Java projects, accounting for 30.80% of the crash reports (1368/3437); (2) programmers concern on nested exception reports more than non‐nested ones; (3) the number of comments in nested exception reports correlates with the lifecycle of crash reports; (4) a parameterized constructor with an object of Throwable and the use of throw keyword highly correlates with the number of nested exception reports; and (5) without modifying the semantics of source code, programmers can simplify complex nested exception reports by eliminating a parameterized constructor with an object of Throwable class in the line of throwing an exception. [ABSTRACT FROM AUTHOR]
ISSN:20477473
DOI:10.1002/smr.70099