DB Access Exception Handling Policy: Difference between revisions
Jump to navigation
Jump to search
(Created page with '==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 Exc…') |
No edit summary |
||
Line 5: | Line 5: | ||
=== Exception Handling=== | ===Exception Handling=== | ||
* '''Scenario 1''': just reading data | * '''Scenario 1''': just reading data | ||
** '''Way 1''': Commit before first Catch Clause + Commit in Catch Clause(s), no Finally Clause | ** '''Way 1''': Commit before first Catch Clause + Commit in Catch Clause(s), no Finally Clause |
Revision as of 09:29, 9 Mayıs 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!!!
- Advantage:
- 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.
- Way 1: Commit before first Catch Clause + Commit in Catch Clause(s), no Finally Clause
- 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.
- Advantages:
- 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.
- Way 1: Commit before first Catch Clause + Rollback in Catch Clause(s), no Finally Clause
DB Transaction Handling
- handling of long running DB Transaction over many Method Calls ('Control Method' / 'Super Structure')
- Discussion: http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=364#p364
- Starting of a local DB Transaction or use of a Session Object?
- Exception handling
- Discussion: http://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?p=364#p364