Reentrance after a thrown exception

wolfganguhr

Hello

Actually I try to catch an error message, show the error to the user and continue. This is not possible if the exception is throw by the server.

Elsewhere in my server code I put the following sequence.

            ApplicationException apEx = new ApplicationException("TEST");
            TerminateException terminate = new TerminateException(apEx,"Demo");
            terminate.ErrorCode = "LedgerInfo.01";
            terminate.Context = "Database Request";
            throw terminate;

The ApplicationException is a representant of any other exception which is actually thrown. My idea is to catch this exception, put it - together with some other more specific information in a "outer Exception" and throw this again. Then and the end of my routine I will specially catch only the TerminateException, put this into a new TVerificationResultCollection and send this back as an answer. Then you get the following Message.

The problem is: If you do this a second time, it will not work again. You will get the a "very long" error message.

One reason is:

            TDBTransaction transaction = DBAccess.GDBAccessObj.BeginTransaction();

        ApplicationException apEx = new ApplicationException("TEST");
        TerminateException terminate = new TerminateException(apEx,"Demo");
        terminate.ErrorCode = "LedgerInfo.01";
        terminate.Context = "Database Request";
        throw terminate;

        ledgerNumber = ALedgerNumber;
        ledger = ALedgerAccess.LoadByPrimaryKey(ALedgerNumber, transaction);
        DBAccess.GDBAccessObj.CommitTransaction();

If the exception is thrown between a BeginTransaction and a CommitTransaction and you do not commit, you have lost the game.

Only the following sequence helps.

            DBAccess.GDBAccessObj.CommitTransaction();
            TDBTransaction transaction = DBAccess.GDBAccessObj.BeginTransaction();

        ApplicationException apEx = new ApplicationException("TEST");
        TerminateException terminate = new TerminateException(apEx,"Demo");
        terminate.ErrorCode = "LedgerInfo.01";
        terminate.Context = "Database Request";
        throw terminate;

        ledgerNumber = ALedgerNumber;
        ledger = ALedgerAccess.LoadByPrimaryKey(ALedgerNumber, transaction);
        DBAccess.GDBAccessObj.CommitTransaction();

So: Run a "DBAccess.GDBAccessObj.CommitTransaction();" as one of the first lines in your code.

Best regards
Wolfgang

christiankatict

Issue one: Re-entrance
This will not be an issue if there is a try-finally clause which encloses the DB commands. Before the try-finally command you open a transaction, and in the finally code you either commit or roll back the transaction, depending on a flag you set in code before. This way in case an Exception is thrown in the try-finally code block, the running transaction is rolled back. You won't have a problem executing this method (and other methods that want to open a DB transaction!) afterwards again. So re-entrance should not be a problem.

So: Run a "DBAccess.GDBAccessObj.CommitTransaction();" as one of the first lines in your code.

This would be very dangerous: the programmer does not know what he/she is committing there, as a running transaction could be left over from virtually any operation on the server side!!!

Issue two: Use of Exceptions for Error Handling
I am not in favour of putting Exceptions into a TVerificationResultCollection unless you need to gather several TVerificationResult instances and want to send them back all at once to the Client. Exceptions should be used for rare and exceptional circumstances (e.g. a needed system setting not being present in the DB) but not for routine error handling or data verification purposes.
Another way of achieving the returning of a TVerificationResultCollection is having an output parameter like 'out TVerificationResultCollection AVerificationResult' and return a bool value for Methods you call. The bool value is set to false if there was anything put into AVerificationResult and is in turn inspected in the main routine. You can then pass that TVerificationResultCollection in the main routines' AVerificationResult out parameter to the Client. You can find examples for that in the server code, e.g. in Partner.PartnerEdit.cs, Method 'SubmitChanges'.

wolfganguhr

So re-entrance should not be a problem.

Ok, but if it gets a problem. Assume that the version 1 is delivered and the user - no developer experience - has done something. And now we have the problem. What shall we do? How shall the sofware act in this problem.

I am not in favour of putting Exceptions into a TVerificationResultCollection unless you need to gather several TVerificationResult instances and want to send them back all at once to the Client.

No, that was not the idea. The idea was that the program works and the user gets the messages he need for his work. But if something went wrong then I throw away the status messages for the user and replace them with a message containing the information about the exception(s). So he can phone and we an discuss the problem. And in 99,9% (I hope more) the user sees "his" data.

We just discuss the 0,1% or less ...

christiankatict

Ok, but if it gets a problem. Assume that the version 1 is delivered and the user - no developer experience - has done something. And now we have the problem. What shall we do? How shall the sofware act in this problem.

I'm sorry, I don't quite get what you mean. Can you elaborate on this, please.

Exceptions can happen at various stages in various screens and can usually be recovered by the user by closing and re-opening that screen or restarting the whole application; in some rare cases a PetraServer restart might be necessary. What is special about the case you are working on that it would require a different handling of an Exception situation?

No, that was not the idea. The idea was that the program works and the user gets the messages he need for his work. But if something went wrong then I throw away the status messages for the user and replace them with a message containing the information about the exception(s). So he can phone and we an discuss the problem. And in 99,9% (I hope more) the user sees "his" data.

It isn't a good idea to catch Exceptions and display them in some textual format to the user, unless it is a specific exception that you know can happen at a certain stage and in which you can give clear guidance to the user what to do about it. (In such a case where you know what advice to give to the user, creating a TVerificationResult on the server side could be a good idea.)
In all other cases, an Exception should 'bubble' up through catch clauses and be dealt with, or be allowed to become an 'unhandled Exception', in which case our default Unhandled Exception handler will catch it and show the Unhandled Exception dialog. That shows a friendly message to the user, but also captures the Exception with a complete stack trace and saves it automatically to the log file, and allows the user to send an email to his support staff (whoever that is!) containing all the Exception details and stack trace, and to restart the application if the Exception means that the application is unrecoverably screwed up, all in one neat user interface.

christiankatict

Sorry, clarification needed:

(In such a case where you know what advice to give to the user, creating a TVerificationResult on the server side could be a good idea.)

With that I didn't mean sticking the content of an Exception into a TVerificationResult, but I meant that you could create a TVerificationResult that contains advice to the user.

Creating a TVerificationResult on handling an Exception is a good idea if that Exception is thrown in a data verification situation, or when you need to read some values from the DB but the expected record isn't there, which is also a verification step.
The point is: you will need to deal intelligently with the Exception and hence know what kind of situation causes it to be able to tell the user exactly what is wrong and what can be done about it. If you don't have that information in the very context where the Exception happens, let the Exception 'bubble up' as it is unexpected and needs inspection from the software support team (most likel 2nd or 3rd level support); don't stick it in a TVerificationResult.

wolfganguhr

Hi Christian

Ok let us speak about an example

        public decimal YtdForeign
        {
            get
            {
                try
                {
                    return (decimal)aGLM.Rows[iPtr][AGeneralLedgerMasterTable.GetYtdActualForeignDBName()];
                }
                catch (IndexOutOfRangeException)
                {
                    return 0;
                }
                catch (InvalidCastException)
                {
                    return 0;
                }
            }
        }

I've a class which reads the glm-data and here I've to read YtdForeign. Two types of Exceptions are handled properly. The IndexOutOfRangeException ist thron if the requested entry does not exists (The database has no value) and the InvalidCastException is thrown if the entry is not initialized yet. In both cases the result value 0 is the correct answer for the problem. But I need something to do with a "ServerRoomHasJustBurnedOutException" or the "DriveTemperatureTooHighException" or else.

Best regards
Wolfgang

christiankatict

Hello Wolfgang,

But I need something to do with a "ServerRoomHasJustBurnedOutException" or the "DriveTemperatureTooHighException" or else.

In these cases (and any other unknown cases) you can only let an Exception (whichever it is) 'bubble up' to the surface and let the 'Unhandled Exception Handler' display the 'Unhandled Exception' - or can you somehow intelligently react in such (or even completely unknown) situations??? - I don't think so!

Your server-side code only needs to make sure that a running DB transaction is rolled back and any extra clean-up, if needed, is done properly before any Exception 'bubbles up' (e.g. delete files in the file system which need to be deleted because of an unexpected abortion of a specific running process).

wolfganguhr

Ok, than I've missunderstood your Error and Exception Handling Policy a little bit. I've thought that you would not have had a thrown exception between server and client. But this is ok.