Error Handling - The Concept (Magic xpa 3.x)

Magic xpa has an error handling mechanism designed to take the headache of handling errors away from the developer. There are a few levels at which database errors are handled by Magic xpa. The first and foremost level is handled by the engine itself or the Magic xpa internal gateway for that DBMS. Let us take our example of Wilma trying to create a new Savings account for her daughter. The application enables the client to select which account number they would like to have from a list of available numbers. So the bank clerk displays this lovely list to Wilma and she sees that account number 301 is available. Wow, what luck! Her account is 300, easy enough to remember. So she chooses this number and the clerk enters the details. But, since they are working in a multi-user environment, someone else was quicker and chose that number. When the transaction is committed, the bank clerk will get an error message. The error message that will be seen is “Duplicate Index, Table: accounts”. This is an error generated by Magic xpa. The actual error message from the DBMS depends on the DBMS itself. For instance, an error message from MSSQL 2000 may be something like: “Cannot insert duplicate key row in object ‘history’ with unique index ‘trans’”. For Oracle, it will be totally different. Within Magic xpa, the message will be the same for all databases.

Looking at this, how does it help us? In most cases, this is more than enough. But suppose for a moment that you had a long transaction continuing through a few tasks and when you committed this transaction, you received the error. What do you do now? It would be nice to be able to provide your own screen that will enable the user to fix the error, or in our case to provide a new account number. As a result, Magic xpa enables the developers to provide their own developer-defined handling of this error. As George Washington once said “To err is natural; to rectify error is glory”.

The developer-defined error handling mechanism works in the same way as Magic xpa’s internal event handling mechanism. You define a handler of type Error.

So how does this work? The engine encounters a DBMS error; it raises the Error event, for example our “Duplicate Index” error event. The engine now looks for a handler to handle this error, according to the error name. It starts searching in the current task, along the runtime task tree until it reaches the Main Program. If the error handler exists, Magic xpa performs the operations that are defined for the handler, and then performs the corresponding action according to the Engine Directive property that was evaluated by the handler.

If the required error handler does not exist, and a handler for “Any” is defined, the error handler for “Any” is executed.

If it does not find a handler, it will revert to the default error handling mechanism that gives the message.

In order to understand more about the event handling mechanism, you should read the concept paper called Event-Driven Architecture, which explains this mechanism in depth.

Let us use the Duplicate Index situation as an example of what can be done. We can create an error handler for Duplicate Index. Within that handler, we can call a program of our own that displays the error and enables the user, in this case the clerk, to fix the error. We can add as much information as we want, to ensure that the clerk will know what to do.

The Cancel button, in the above example, may simply perform a Rollback of all the work that resulted in this error.