db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (DERBY-5803) Make error handling in xaHelper more explicit
Date Mon, 11 Jun 2012 12:35:43 GMT

     [ 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:
         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:
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>            Priority: Trivial
>             Fix For:
>         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


View raw message