DB Access Exception Handling Policy: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 15: Line 15:
*** ''Advantage'': Commit can never be forgotten about - this is also true for the case where a 'return' statement is executed in the 'try' code block of the try-catch-finally Clause!!!
*** ''Advantage'': Commit can never be forgotten about - this is also true for the case where a 'return' statement is executed in the 'try' code block of the try-catch-finally Clause!!!
*** ''Disadvantage'': Finally Clause is needed, therfore deeper nesting of code.
*** ''Disadvantage'': Finally Clause is needed, therfore deeper nesting of code.
'''Recommendation''' (ChristianK): We should discourage 'Way 1' and ensure that 'Way 2' is implemented everywhere.


* '''Scenario 2''': Writing Data / mixed reading/writing of data
* '''Scenario 2''': Writing Data / mixed reading/writing of data
Line 30: Line 33:
**** bool Variable needed.
**** bool Variable needed.


'''Recommendation''' (ChristianK): We should discourage 'Way 1' and ensure that 'Way 2' is implemented everywhere.





Revision as of 09:32, 9 May 2011

Overview

We do not yet have a consistent way of handling DB Access Exceptions in all situations. This is strongly desired.

TODO: Improve section on DB Access Exceptions in the Error and Exception Handling Policy.


Exception Handling

  • Scenario 1: just reading data
    • Way 1: Commit before first Catch Clause + Commit in Catch Clause(s), no Finally Clause
      • Advantage:
        • No Finally Clause needed, therfore less deep nesting of code.
      • Disadvantage:
        • Commit can be accidently forgotten about by developers, leaving an open, 'dangling' DB Transaction - this is also true for the case where a 'return' statement is executed in the 'try' code block of the try-catch Clause!!!
    • Way 2: Commit in Finally Clause which encloses try-catch Clause
      • Advantage: Commit can never be forgotten about - this is also true for the case where a 'return' statement is executed in the 'try' code block of the try-catch-finally Clause!!!
      • Disadvantage: Finally Clause is needed, therfore deeper nesting of code.

Recommendation (ChristianK): We should discourage 'Way 1' and ensure that 'Way 2' is implemented everywhere.


  • Scenario 2: Writing Data / mixed reading/writing of data
    • Way 1: Commit before first Catch Clause + Rollback in Catch Clause(s), no Finally Clause
      • Advantages:
        • No Finally Clause needed, therfore less deep nesting of code.
        • No bool Variable needed (see below).
      • Disadvantages:
        • Developers must not forget to do a Rollback in ANY Catch Branch!
        • Commit can be accidently forgotten about by developers, leaving an open, 'dangling' DB Transaction.
    • Way 2: Commit or Rollback in Finally Clause which encloses try-catch Clause, depending on value of bool Variable ('SubmissionOK'). DB Transaction is not committed before first Catch Clause and not Committed / Rolled Back in any Catch Clauses. (Example: C:\openpetraorg\trunk\csharp\ICT\Petra\Server\lib\MSysMan\UserDefaults.cs, line 964)
      • Advantage: Commit or Rollback can never be forgotten about - this is also true for the case where a 'return' statement is executed in the 'try' code block of the try-catch-finally Clause!!!
      • Disadvantages:
        • Finally Clause is needed, therfore deeper nesting of code.
        • bool Variable needed.

Recommendation (ChristianK): We should discourage 'Way 1' and ensure that 'Way 2' is implemented everywhere.


DB Transaction Handling