| Home | Previous Lesson: Prompt for Criteria Next Lesson: The Continue CommandButton |
Till now, we wrote lot of code. In some places we checked the returned codes of functions, and in some places we skipped it. Every programmer thinks that (s)he wrote the perfect code and it's going to work excellently, but not in software. Remember one thing, no matter how many times you test, it's still not enough. So, if something that we didn't expect at design/development time happens, let's not blow the application. We need to provide some door where we can inform the error to the user, and let him decide the future action.
PowerBuilder provides an event to trap errors, i.e., SystemError event at the application object. When an error (of course not all errors) occurs in the application, the script written for this event is executed.
Whenever an error occurs, PowerBuilder populates the error information in a global object namely Error. The Error object is one of the built-in global objects used by PowerBuilder. Error object has the following structure:
|
Property |
Datatype |
Meaning |
|
Error.Number |
Integer |
PowerBuilder error number. |
|
Error.Text |
String |
Error message. |
|
Error.WindowMenu |
String |
Name of the Window or Menu object in which the error occurred. |
|
Error.Object |
String |
Name of the object in which the error occurred. If an error occurs in a window or a menu, this string will be the same as Error.WindowMenu. |
|
Error.ObjectEvent |
String |
The name of the event where the error occurred. |
|
Error.Line |
Integer |
The line number where the error occurred. |
When an error occurs, SystemError event is triggered at the application level and PowerBuilder displays its default error message. In most cases, the application will terminate. Every time we get an error we don't want our application to terminate, so we trap these errors by writing code for the SystemError event.
Even a single line of comment that is added to the SystemError event allows us to continue executing our application. Unfortunately, this still doesn't help if the error is a General Protection Fault (GPF). In that case, except for closing the application there's little that can be done.
Open the application painter and add the following code to the SystemError event:
// Object: Application
// Event SystemError
Open(w_error)
This opens up the w_error window painted in window painter session. Now, let's display the error information. For that, we need to write some code in the open event of w_error window.
Open the w_error window and associate d_error_info_display DataWindow object with dw_error_info DataWindow control. (Forgot about associating a DataWindow object? then do this. Go to properties for the dw_error_info DataWindow control and type d_error_info_display for the "DataWindow Object Name" prompt.)
Write the following code for the open event of "w_error" window.
// Object: w_error
// Event: Open
dw_error_info.insertrow(0)
dw_error_info.SetItem( 1, "Error_No", error.Number)
dw_error_info.SetItem( 1, "Error_Message", error.Text)
dw_error_info.SetItem( 1, "Error_Line_No", error.Line)
dw_error_info.SetItem(1,"Error_WindowMenu", &
error.WindowMenu)
dw_error_info.SetItem( 1, "Error_Object", error.Object)
dw_error_info.SetItem( 1, "Error_Object_Event",
error.ObjectEvent)
The first statement is inserting a row into the DataWindow. Obviously it would be row number one, since we don't have any rows. As you know, when we insert a row it is blank. We need to populate this blank row with the error information; the information we got from the Error object. We can change the value of a field in the DataWindow by calling SetItem() function. It takes three parameters, row number, column number/name, and value.
Now we have to add some functionality to the CommandButtons on the window. We have four CommandButtons that allow us to continue with the application, abort the application, print the error messages or save them to a log file.
| Home | Previous Lesson: Prompt for Criteria Next Lesson: The Continue CommandButton |