You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <ji...@apache.org> on 2012/06/11 14:35:43 UTC

[jira] [Resolved] (DERBY-5803) Make error handling in xaHelper more explicit

     [ https://issues.apache.org/jira/browse/DERBY-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kristian Waagan resolved DERBY-5803.
------------------------------------

       Resolution: Fixed
    Fix Version/s: 10.10.0.0
         Assignee: Kristian Waagan

Thanks, Knut and Dag.
I agree none of the approaches are perfect. The forgotten throw is something the other approach suffers from too, but there it's normally a more subtle bug (i.e. a bug in a switch statement or broken logic in if-statements) where an exception is thrown in most cases but not all.

Committed patch 1a to trunk with revision 1348818.
                
> 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
>            Assignee: Kristian Waagan
>            Priority: Trivial
>             Fix For: 10.10.0.0
>
>         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