The onerror statement can be used to catch all errors that are not trapped by if error or try statements.


This statement has one parameter:

statements – is a text string that contains one or more Panorama statements to be executed when an error occurs. Notice that this is not the name of a procedure, but the actual statements themselves (as a string of text). This is similar to the execute statement. Once an error has occurred, these statements will run. Within these statements you can use the info(“error”) function to find out what the error was, if necessary.


The onerror statement can be used to catch all errors that are not trapped by if error or try statements. This has two benefits: 1) It allows the programmer to easily eliminate all error alert dialogs. This is very important for server applications because an alert dialog requires human intervention to get the server going again. 2) It makes it easy to build a log of errors.

When Panorama encounters an error, it checks to see if the next line is if error. If not, it usually stops and displays an error message. However, if an onerror statement has been encountered, Panorama will not stop and will not display an error message. Instead, it will execute the statements specified as the parameter to the onerror statement.

The effect of the onerror statement ends when the main procedure stops running. In other words, onerror isn’t a permanent error handler – you must specify it for each procedure you wish to have error trapping. If you plan to use onerror, it is probably best to put it in the first line of any procedure that needs error trapping. If you are going to use the same statements with onerror in several different procedures, you may want to set up the statements in a variable in your .Initialize procedure, then use that variable as the parameter to onerror.

It’s important to consider the possible environment that may exist when an error occurs. Depending on the flow of your main procedure, Panorama may not be in the same window or even in the same database. Your onerror program should generally not make any assumptions about what windows or databases will be active or available when the error occurs.

Here is an example of how onerror could be used in a CGI (web server) application. In this example, if there is an error, Panorama will return an error message to the web server and also log the error along with the date and time.

global cgiResult,errorLog
errorLog=errorLog // make sure errorLog exists
if error
   errorLog="" // initialize errorLog
onerror {cgiResult="Panorama Error: "+info("error") }+
       {datepattern( today(),"DD/MM/YYYY ")+}+
       {timepattern( now(),"hh:mm:ss")+}+
// error logging is set up, now we can continue with our tasks
... rest of this procedure

Note that you should be very careful when setting up your onerror code. If your onerror code itself contains an error, that error will not be trapped and a message alert will appear. In that case, Panorama will display the original error message, plus a message indicating that there is a problem with the onerror code

See Also


10.0UpdatedCarried over from Panorama 6.0, but now if the onerror code itself has an error the message alert will display both the original error and the fact that there is an error in the onerror code.