[jira] [Commented] (CASSANDRA-15113) StorageService.decommission() throws RuntimeException when interrupted, which results in dead code in Decommission.execute()

["Jon Meredith (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-15113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836673#comment-16836673 ] 

Jon Meredith commented on CASSANDRA-15113:
------------------------------------------

I agree the rethrown exception will not be caught / handled in {{org.apache.cassandra.tools.nodetool.Decommission}}, however {{org.apache.cassandra.tools.NodeTool}} 3.11 L184 will catch all throwables and exit non-zero as desired.

Briefly hacking up the code shows {{nodetool}} exits non-zero on runtime exception.

{panel:title=nodetool output}
error: fake RuntimeException for CASSANDRA-15113
-- StackTrace --
java.lang.RuntimeException: fake RuntimeException for CASSANDRA-15113
        at org.apache.cassandra.tools.nodetool.Decommission.execute(Decommission.java:33)
        at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:255)
        at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:169)


Process finished with exit code 2
{panel}

The wrapped runtime exception could wrapping the two checked exceptions could pass on the inner exception,
but again without anything broken I don't want to make changes in the minor.

> StorageService.decommission() throws RuntimeException when interrupted, which results in dead code in Decommission.execute()
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-15113
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15113
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: eBugs
>            Priority: Normal
>
> Dear Cassandra developers, we are developing a tool to detect exception-related bugs in Java. Our prototype has spotted the following {{throw}} statement whose exception class and error message indicate different error conditions.
>  
> Version: Cassandra-3.11 (commit: 123113f7b887370a248669ee0db6fdf13df0146e) 
> File: CASSANDRA-ROOT/src/java/org/apache/cassandra/service/StorageService.java
> Line: 4008 
> {code:java}
> try
> {
>     ...
>     Thread.sleep(timeout);
>     ...
>     unbootstrap(finishLeaving);
> }
> catch (InterruptedException e)
> {
>     throw new RuntimeException("Node interrupted while decommissioning");
> }
> {code}
>  
> {{RuntimeException}} is usually used to represent errors in the program logic (think of one of its subclasses, {{NullPointerException}}), while the error message indicates that an interrupt has occurred. This mismatch be a problem. For example, the callers may miss the possibility that {{StorageService.decommission()}} can be interrupted because it does not throw any {{InterruptedException}}. Or,  the callers trying to handle other {{RuntimeException}} may accidentally (and incorrectly) handle the interrupt.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org