ON ERROR and pipes?

[vefatica]

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.

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:

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:

v:\> batch3.btm use_on_error | sort

v:\>

 

[rconn]

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?

 

[vefatica]

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.

 

[vefatica]

And ON ERROR is not only easier, it suppresses error messages. Without it *I* have to worry about suppressing error messages.

 

[rconn]

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.

 

[vefatica]

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.

 

[vefatica]

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.

 

[AnrDaemon]

I can't call an obvious bug "working as designed".

 

[rconn]

There is no "obvious bug". TCC closes the child pipe process to prevent collateral damage on an error. And it has worked this way for 20+ years.