Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.
Keywords: suppress errors
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?
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 :WBERRORHANDLERThis 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.
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.
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