db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5803) Make error handling in xaHelper more explicit
Date Fri, 08 Jun 2012 12:56:23 GMT

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

Knut Anders Hatlen commented on DERBY-5803:
-------------------------------------------

+1

I like the pattern where we explicitly throw the exception better, as then we don't have to
trick the compiler by inserting unreachable return statements. The only downside I can see,
is that bugs can be introduced if someone forgets the "throw" keyword, and this won't be detected
by the compiler. However, I think that disadvantage is outweighed by the benefit that the
control flow is easier to understand.
                
> Make error handling in xaHelper more explicit
> ---------------------------------------------
>
>                 Key: DERBY-5803
>                 URL: https://issues.apache.org/jira/browse/DERBY-5803
>             Project: Derby
>          Issue Type: Improvement
>          Components: Tools
>    Affects Versions: 10.10.0.0
>            Reporter: Kristian Waagan
>            Priority: Trivial
>         Attachments: derby-5803-1a-explict_throw.diff
>
>
> In xaHelper the method handleException returns nothing (void), but it always throws an
exception. Typically used inside a catch-block, this pattern confuses (static) code analyzers
and reduces code readability.
> In this case it is possible to make the method return SQLException and write "throw handleException(t)",
which makes it clear that the flow will stop if it reaches the catch block. Note that the
method may still throw a RuntimeException, which I will document in the method Javadoc.
> The latter pattern is other places in the Derby code base, but I haven't checked for
consistency. One specific case worth mentioning is the one in DRDAConnThread. This one is
different in that it only takes correct actions, but doesn't actually throw an exception since
we wan't the server thread to keep processing/executing after having cleaned up and informed
the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message