Inconsistent Error and Exception Handling

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 ThiasG

Expected System-Exceptions shall be caught and be put into an OpenPetra-specific Exception. This help to differentiate between programmed errors and expected Exception conditions.

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 extreme cases, such as

• Losing connection to DB;
• Client-Server/Server-Client connection;
• other cases?

What to do in such situations: Do we stop the client session? In which cases the server needs to stop? - Not all error conditions are initiated by a function call from the client.

--Thiasg 09:27, 31 January 2011 (UTC)

2.Input from ThiasG

I would throw an Exception for verification errors. Otherwise this would be a extra condition to think of. There should be a special Exception Class for verification errors, which include the TVerificationResult and TVerificationResultCollection objects for information about the verification error.

I would not allow to "translate" an exception with one exception: Putting a database error into a OpenPetra specific exception. But as general rule, translation should not be done and not be allowed.

All Exception we are throwing should be custom exceptions deriving from OPDBExcpetion and OPAppException (perhaps some more, eg on for the verification errors). By this it is possible to catch exceptions by catching only some types of exception we are interested in.

Example of use case does not make sense. The exception should not catched, because it is not handled at this point of code! The information, that it is the ledger 44, is an internal information, a end user is not interested in. This information is available in the debugger through the stacktrace anyway. Writing a log and rethrowing the original exception would be sufficient. The problem with catching and rethrowing is, that in most cases it is harder to debug, because the exception is handled and the original cause is hard to find.

CancelSaveException sounds weird: The exception is mis-used as flow control. In which cases the save operation is canceled, after a verification was already done? Why is it not possible to throw a custom exception with the specific information, which is shown later on after rollback to the user? --> This has been addressed in [Bug 1503] - CancelSaveException has been removed; the Data Validation Framework is used instead.

--Thiasg 07:51, 9 May 2011 (UTC)