Inconsistent Error and Exception Handling

From OpenPetra Wiki
Revision as of 09:14, 31 Ocak 2011 by Thiasg (talk | contribs) (Feedback to Policy for exception handling)
Jump to navigation Jump to search

Overview

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

TODO: Extend the Error and Exception Handling Policy - especially in the areas of Client and Server error handling.

Input from Wolfgang U

Section Practices That Need to be Adhered to:

      • Another part of re throwing an exception is a proper reaction of an error message (ref. Comments to Revision 1089#A new common Exception: CancelSaveException). In this case the error handling has been done inside of the exception handler joined with a appropriate error message and then a large part of manual code and automatic generated code shall not to be done. One example of this is the CancelSaveException which is defined in PetraEditForms.cs. This exception is thrown in GLAccountHierarchy.ManualCode.cs. In the try block in specific situations a System.Data.ConstraintException is thrown.


Input from ThiasG

  • An exception shall never be caught and re-thrown with one exception: Resources need to be freed in error case, e.g. SQL transaction rollbacked, handles freed, wait cursor reseted, what-ever.
  • Expected System-Exceptions shall be caught and be put into a OpenPetra specific exception. This help to differentiate between programmed errors and expected error conditions.
  • Exceptions, which are a result of a programming error shall never be caught, e.g. NullPointerException. This would mask the original error making it hard to find it.
  • If there is additional information for an exception when it is thrown, then it should be added in extra attributes to the exception. This help in handling the exception, because it is possible to process the additional data in the code. Also it is possible to show a i18n error including the additional data. (Is this possible in C# like in C++/Python?)
  • All OpenPetra specific Exception shall derive from the base class XXX. The base class adds support for i18n of the Exception for showing an error message to the user. Exceptions should always logged in English to the log file (without i18n).
  • Specialized base class for exception for database, IO, server-communication, ... are provided. This helps to catch specific areas of expected exception, which could be handled in this place.
  • Exceptions should not be used to change the flow control. Exception shall only be used for error conditions.

I would remove the part of specialization. Often you throw a specialized exception like System.IO.Exception because e.g. a file is not found, but from the point of view of caller of the function/method, e.g. cached data is not accessible and is a more appropriate error then the file is not found message. Internally it is important to have the original exception, which needs to be logged, too.

Until now, we have not added anything about handling the exception, e.g. handling the exception in the client, aborting the current function, logging the exception and showing the error to the user.

We need to add something about handling the extreme cases of losing connection to DB or errors in the Client-Server/Server-Client connection. Do we stop the client session? In which cases the server needs to stop? Not all error condition are initiated by a function call from the client.

Retrieved from ‘https://wiki.openpetra.org/index.php?title=Inconsistent_Error_and_Exception_Handling&oldid=1668’