WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

Error Codes

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

How to suppress error displays

Keywords:      suppress errors

Question:

I'm working on scripts to "babysit" batch jobs running unattended, automatically closing dialog boxes such as GPFs and instead writing error codes to a text file for processing by the automated scheduler. Since the scripts are specifically meant to run unattended, obviously we don't want dialog boxes displaying -- even in the case of critical errors -- since there is no user present to handle them.

Is there any way for me to suppress WinBatch's error dialogs? Ideally, I would like to have any error -- especially critical errors -- execute custom error-handling code instead of displaying a user dialog. If I can simply end the WinBatch script without displaying a dialog, this would be acceptable.

In an operations-run batch environment, these message boxes are completely unacceptable. Do you anticipate a future release of your product to give the users the ability to eliminate the message boxes? If not, why not?

Answer:

Note: Starting in WinBatch version 2000B, see the function IntControl(73, p1, 0, 0, 0). IntControl 73 sets Error handler.

This IntControl lets you specify what should happen when the next error occurs in the script.

        P1  Meaning
        --  -------
        -1   Don't change (just return current setting)
         0   Normal error processing (default)
         1   Goto the label :WBERRORHANDLER
         2   Gosub the label :WBERRORHANDLER
This is a one-time flag, which gets reset to 0 after the next error occurs.

When processing goes to :WBERRORHANDLER, the following WIL variables are automatically set:


        
	Variable                  Type     Meaning
	--------                  ----     -------
	wberrorhandlerline        string   Error line (ie, line in script that caused Error)
	wberrorhandleroffset      integer  Offset into script of error line, in bytes
	wberrorhandlerassignment  string   Variable being assigned on error line, or "" if none
	wberrorhandlerfile        string   Name of the currently-executing script
	wberrortextstring         string   Description of the WIL error
	wberroradditionalinfo     string   Additional error information, if any
	wberrorinsegment          string   name of the currently-executing UDF, or a blank string ("") if not in a UDF.
	wberrorarray              array    WIL array with the following elements:
	                                   wberrorarray[0] = LastError()
	                                   wberrorarray[1] = wberrorhandlerline
	                                   wberrorarray[2] = wberrorhandleroffset
	                                   wberrorarray[3] = wberrorhandlerassignment
	                                   wberrorarray[4] = wberrorhandlerfile
	                                   wberrorarray[5] = wberrortextstring
	                                   wberrorarray[6] = wberroradditionalinfo
	                                   wberrorarray[7] = wberrorinsegment



      Note: The :WBERRORHANDLER label must be in the same script where the
      error occurred.  If an error occurs in a called script, it will go to
      the label in the called script, not the calling script.
 
Returns previous setting.

*OR*

With the WinBatch ErrorMode and LastError functions you can also automate the handling of all 1000 level errors. 2000 and 3000 level errors will require user intervention.

If you want to trap your error, then in front of the Run Command, turn Error Mode off (be very very careful here to isolate turning error mode off), run your app, turn error mode back on, then immediately after, use the Lasterror function to trap the error, as in the following example:

     LastError( )       ;; This sets the error memory to zero     
     ErrorMode(@OFF)    ;; This tells WB we are handling the errors ourselves and not to bother the script.       
     Run(statement just like it originally was)     
     ErrorMode(@CANCEL)    ;; This hands control back to WB, which will look for error messages.      
     If LastError( ) !=1932 then Message("Script Died", "Run Error is not 1932")  
             
     Exit   ;; This stomps on other errors but lets Error 1932 pass through, so it is never seen.

Note: != means Not Equal.

You can find a list of the error numbers in the WIL help file.

*IMPORTANT* Don't even consider using ErrorMode without a note from your mom. Improper use of Errormode can make a 5 minute debugging project last 6 weeks.

WinBatch was initially designed for running of debugged scripts, under the theory that the programmer would be in front of the computer during the debugging process.

If the undebugged scripts are submitted to a remote computer for execution on the remote computer, the error messages will come up on the remote computer.

The 1000 level errors (the trappable ones) deal with situations the programs can encounter on the machines they are running on (network connection down, file does not exist, etc) Whileas the 2000-3000 level errors tend to be ones that are real errors in the script itself - unrecognised functions, bad syntax, etc.

People have gotten into tremendous amounts of trouble using the error mode function - so much so that we are considering getting rid of Errormode and replacing it with a statement that will suppress errors for the immediately following statement only... The mantra being "Using ErrorMode on an undebugged script will turn a 5 minute debugging project into a 6 week debugging project."

OTOH, the WebBatch product was designed to not *ever* stop processing, but instead return the error message to the users browser. It is a way to submit scripts for remote execution and not have the remote machine keel over.

Part of the problem may be semantic. What does "Batch" mean. There used to be no problem - there was PC BATCH in the forms of BAT files that ran a list of commands on the users PC in batch mode -- and there was mainframe batch, where a series of commands were submitted to a remote machine for non-real-time processing. Now that PC and mainframes are beginning to merge, a lot of people from the mainframe environment see the "batch" part of WinBatch and see it as a way to batch jobs on a remote PC.

The Batching on a remote PC works if the scripts are debugged, but is not an ideal way to have users generate scripts and run them remotely.

There are other products available - "LanBatch" from some other company, that is more of a mainframe definition of "batch" in that it can accept jobs and run them remotely, but it is a very very different product.

What we will do. Probably nothing. This is really the first serious request we've had in 8 years to modify the 2000-3000 error trapping code. On first thought, especially with all the problems people have encountered when they suppress 1000 level errors, it seems this would open up Pandora's box to all kinds of horrible problems with irresponsible use of the errormode function.

It might work out to a special version of error mode that can allow the script to survive *any* error on the immediately following line of code. This would allow certain lines to be bulletproofed without opening up the whole machine to wanton destruction.

The most famous case of bad use of error mode was this script, placed in the windows directory for easy access.

	ErrorMode(@off)
	DirChange("C:\temp")
	FileDelete("*.*")
The idea being that the user would occasionally run the script to clear all files out of his temp directory. A year later, because of space considerations he moved the temp directory to D:\TEMP. Then later ran the script without modification. The DirChange error was suppressed, the directory was not changed, and the FileDelete proceeded to delete a number of files from the Windows directory. Keeping most people away from this kind of problem seems more critical than making it easier....

My 2 cents worth.


Article ID:   W12977
Filename:   How to Suppress Error Displays.txt
File Created: 2004:09:27:12:36:44
Last Updated: 2004:09:27:12:36:44