Detecting Bugs in Rethrowing Exceptions

Project summary Due to various considerations, programmers can catch an exception and throw another exception. For example, programmers can be unsatisfied with the specified exceptions of an API method, but cannot modify the source files of API libraries. To bypass the problem, they can rethrow an exception. The prior approaches cannot detect bugs in rethrowing exceptions. It needs complicated rules to rethrow exceptions, but their instances are too few for mining-based approaches to train models. To resolve the problem, we propose a rule-based approach to detect bugs in rethrowing exceptions. Its predefined criterion (meta-oracle) is that the callsites of an API method should follow the same rule to rethrow exceptions as the other callsites of this method do. Our replicate data We checked out the master commits of all our subjects in Apr. 2023. For each project, the class folder lists the results when the scope is within files, and the pak folder lists the results when the scope is within packages. Each folder has three files. log.txt lists all extracted links. A sample link is as follows: link:------------------------------------------------------------ -:StageArtifacts.java:sendPost java.lang.InterruptedException:check-> java.io.IOException:check call:java.net.http.HttpClient#send It says that in the sendPost method of StageArtifacts.java, java.net.http.HttpClient#send is called. This method call is put inside a try statement. Its InterruptedException is caught and IOException is rethrown. The code is as follows: private String sendPost(String serviceEndpoint, String contentType, int expectedStatus, byte[] bytes) throws IOException { URI target = nexusUri.resolve(serviceEndpoint); try { HttpResponse.BodyHandler<String> bodyHandler = HttpResponse.BodyHandlers.ofString(StandardCharsets.UTF_8); HttpRequest req = HttpRequest.newBuilder() .POST(HttpRequest.BodyPublishers.ofByteArray(bytes)) .header("Content-Type", contentType) .uri(target) // we could use json if XML is too difficult to work with. // .header("Accept", "application/json") .build(); HttpResponse<String> response = client.send(req, bodyHandler); if (response.statusCode() != expectedStatus) { throw new IOException("Unexpected HTTP error returned: " + response.statusCode() + ", response body: " + response.body()); } return response.body(); } catch (InterruptedException e) { throw new IOException("HTTP timeout", e); } } Here, the try statement calls multiple API methods. We built the link since send() specifies this caught exception: public abstract <T> HttpResponse<T> send(HttpRequest request, HttpResponse.BodyHandler<T> responseBodyHandler) throws IOException, InterruptedException; conflict.txt lists our found conflicts. bugs.txt lists our found violations of the links without conflicts. Both conflicts and violations can indicate human errors, i.e., bugs. Our reported bugs are as follows: Project URL Status poi https://bz.apache.org/bugzilla/show_bug.cgi?id=66576 confirmed https://bz.apache.org/bugzilla/show_bug.cgi?id=66584 fixed dubbo https://github.com/apache/dubbo/issues/12614 fixed https://github.com/apache/dubbo/issues/12615 fixed cassandra https://issues.apache.org/jira/browse/CASSANDRA-18484 confirmed https://issues.apache.org/jira/browse/CASSANDRA-18527 confirmed lucene https://github.com/apache/lucene/issues/12251 fixed https://github.com/apache/lucene/issues/12240 confirmed jmonkeyengine https://github.com/jMonkeyEngine/jmonkeyengine/issues/2039 confirmed https://github.com/jMonkeyEngine/jmonkeyengine/issues/1999 fixed asm https://gitlab.ow2.org/asm/asm/-/issues/317998 fixed guava https://github.com/google/guava/issues/6598 confirm https://github.com/google/guava/issues/6599 fixed spring https://github.com/spring-projects/spring-framework/issues/30763 confirm https://github.com/spring-projects/spring-framework/issues/30764 fixed azure https://github.com/Azure/azure-sdk-for-java/issues/35692 fixed https://github.com/Azure/azure-sdk-for-java/issues/35693 fixed