ON ERROR and pipes?

May 20, 2008
9,553
64
Syracuse, NY, USA
That other thread was becoming a bit tedious. It seems that DO has nothing to do with it. It's just ON ERROR and a pipe. It's as though when ON ERROR is set and an error occurs, pipes are killed.

Code:
v:\> type batch3.btm
if "%1" = "use_on_error" on error echo ERROR!!!!!
echo 2
dir c:\foobar
echo 1

ON ERROR not set; pipe not killed:

Code:
v:\> batch3.btm | sort
TCC: (Sys) V:\batch3.btm [3]  The system cannot find the file specified.
"C:\foobar"

                   0 bytes in 0 files and 0 dirs
     718,061,199,360 bytes free
Volume in drive C is Windows      Serial number is 3ed6:5d0d
1
2

ON ERROR set; pipe killed:

Code:
v:\> batch3.btm use_on_error | sort

v:\>
 

rconn

Administrator
Staff member
May 14, 2008
11,143
99
WAD.

An ON ERROR condition will check for a child pipe process, and if one is running TCC will do a TerminateProcess API call on that process.

Think about the scenario:

1) You want to send output from the batch file to another process.
2) You're worried enough about the result that you put an ON ERROR in the batch file.
3) You got an error, and you have no way of informing the child pipe process about it.
4) So you want to pretend nothing bad happened, and the child should process bad data?
 
May 20, 2008
9,553
64
Syracuse, NY, USA
WAD.

An ON ERROR condition will check for a child pipe process, and if one is running TCC will do a TerminateProcess API call on that process.

Think about the scenario:

1) You want to send output from the batch file to another process.
2) You're worried enough about the result that you put an ON ERROR in the batch file.
3) You got an error, and you have no way of informing the child pipe process about it.
4) So you want to pretend nothing bad happened, and the child should process bad data?
No to number 4. That's what the ON ERROR is all about ... don't produce output if it's goind to be bad. As for number 3, the child pipe doesn't need to know about it if it's not sent bad outout. That makes more sense to me. What's the alternative ... cancel the whole thing? If I want to continue, I must invent my own test for an error. ON ERROR is easier.

And I could accomplish your goal with ON ERROR LEAVE (if I were piping DO) or ON ERROR QUIT, or ON ERROR GOTO ...

If anything, the default error handler qhould kill the pipe (I am not requesting that). When I say ON ERROR, I want to be in control.
 

rconn

Administrator
Staff member
May 14, 2008
11,143
99
You're assuming (incorrectly in many / most cases) that nothing is going to happen on an error other than an error message being displayed (or intercepted and not displayed). For a DIR, that's true. For COPY / DEL / MOVE / REN -- not so much.

There is 0% chance I'm going to change the current default behavior. If you want to suggest an optional alternate behavior (and its syntax), you should post it on the Suggestions Forum.
 
May 20, 2008
9,553
64
Syracuse, NY, USA
There is 0% chance I'm going to change the current default behavior. If you want to suggest an optional alternate behavior (and its syntax), you should post it on the Suggestions Forum.
They are two very different behaviors. IMHO an (advanced) INI directive, KillPipesOnError=YES|No, would be appropriate. It wouldn't need a spot in the OPTION dialog but it should have a help page which makes it clear that it only applies when ON ERROR is in effect.
 
May 20, 2008
9,553
64
Syracuse, NY, USA
They are two very different behaviors. IMHO an (advanced) INI directive, KillPipesOnError=YES|No, would be appropriate. It wouldn't need a spot in the OPTION dialog but it should have a help page which makes it clear that it only applies when ON ERROR is in effect.
Better yet (for emphasis) ONERRORkillPipes=YES|No or ONERRORKeepPipes=NO|Yes.