Hi Wolfgang,
The TVerifcationResultCollection is a solution for a group of errors which can arise in a set of data base transactions. If you use it to message a single error of type critical you are writing your own exception handling system.
This is a wrong assumption. TVerifcationResultCollection is specifically made for dealing with data verification errors, as it name suggests. As mentioned before, there will be thousands, if no tens of thousands of data verifications in openPETRA and some of those will be client-side, some will be sever-side. We don't want to create an Exception Class for each of those, or even 'just' a few hundred of them (which could bundle some data verifications, e.g. there could be ten data validation checks in the revaluation code, which could all use the RevaluationException).
It is very easy to create and add a TVerificationResult to a TVerifcationResultCollection - much easier than creating a custom Exception, ensuring that it compiles, that it is remoteable, that it has proper XML documentation, then compile the Shared code, finally merge it properly into the Bazaar trunk, etc. A TVerificationResult is also meant to be language-independent (it has a separate ResultText and a ResultTextCaption, both of which can be translated), and a TVerificationResult can have a ResultCode, which can not only be shown as part of an error message, but can also be programmatically evaluated, so no string parsing (which would be language-dependent!) needs to take place if one wants to identify a specific TVerificationResult in a TVerifcationResultCollection.
By separating data validation logic on the Client side from Exception handling, you can focus on real Exceptions in the Exception handling on the Client (Exception Handling would deal e.g. with DB concurrency problems, openPETRA Security-related Exceptions, and general network or DB errors).
At the moment our auto-generated '...SubmitChanges' Methods in the openPETRA Datastore return a TVerifcationResultCollection, but that will be changed with the planned changes on Exception Handling in openPETRA - these Methods will throw a specific Exception instead (with InnerExceptions, if necessary), which can be evaluated and displayed on the client side in a standard way. There isn't really a point in handling database errors in TVerifcationResultCollections, as a database error is always unexpected when data is saved and therefore it is appropriate to raise an Exception in this case, which can escalate quickly and can't be missed.
If the error arises in the production phase, the has just done the first accounts and is in the phase of the first period end. So if the person, which creates the ledger has the experience to handle the English message he will do it. Otherwise he will ask someone of the support team. The member of the support team now can handle a request about what is meant with an RevaluationException or else.
That is not what I want to see happening! A local IT administrator clearly gets worried if he reads the word 'Exception' in a message and concludes something is terribly wrong in the application (wouldn't you, if you as an IT administrator get called by the head of the accounting department and she shows you an Exception in Excel while she is doing your companies budget in it...). In the case of openPETRA the local IT admin would surely escalate the problem up the support stack and a member of the companies 'IT service team' would look into it, who would need to contact the openPETRA development team as they would be worried and not know what to do, and in the openPETRA development team somebody would need to look up in which case the RevaluationException is raised. Now imagine the frustrated openPETRA development team member who finds out that this is actually only a data validation problem, which the application can handle perfectly and keep its data intact, and not an Exception which the application cannot handle!
Handling the TVerificationResults stored in a TVerifcationResultCollection is easy and there is a standard way of dealing with it on the client side. The WinForms Generator will worry about that, and you won't need to write a line of code for it, but the WinForms Generator won't be able to sensibly handle your '101st special circumstance data validation' Exception that you will throw from Class X, Method Y on the server side.
I suggest you wait until the Validation Framework is in place and then see what it is able to do. I admit that there is currently very little information about data validation in openPETRA in the wiki, but that will change once the Validation Framework is in place. Creating the Validation Framework and documentation on it is high on my priority list.
The bottom line is: Create TVerificationResults wherever data validation is done, and throw Exceptions where an Exception is appropriate (i.e., the application cannot handle a situation and might be left in an unstable state).
