Coruption after which BTMs won't run

[vefatica]

The first line of this BTMfile has an error; @LINE's parameters are reversed.

on error (echo Error %_? at line %_batchline: %@line[%@eval[%_batchline-1],v:\error.btm] & quit)
delay 1
dir *.yyy

The first time I run it in an instance of TCC, I see this.

v:\> error.btm
 
Volume in drive V is DATA          Serial number is c007:d3e4
v:\>

Further attempts to run it or any other BTM file in the same TCC unstance fail, resulting in nothing at all. My error has somehow got TCC into a corrupted state in which no BTMfiles run.

If I try it with BDEBUGGER, IDE,EXE crashes thus:

 Fault Module Name:    IDE.EXE
  Exception Code:    c0000005
  Exception Offset:    000127e6

 

[Charles Dye]

I can replicate this, also in older versions going back to about v6. Looks like the error handler is called recursively and getting wound around the axle...?

 

[vefatica]

I can replicate this, also in older versions going back to about v6. Looks like the error handler is called recursively and getting wound around the axle...?

I figured that but TCC neither catches it nor crashes (and is somewhat crippled afterward).

 

[rconn]

The TCC behavior isn't surprising, since you forced it into an infinite loop. The question is what you expected it to do?

TCC eventually aborts the loop when it runs out of stack, but you can't do much else at that point.

 

[vefatica]

The TCC behavior isn't surprising, since you forced it into an infinite loop. The question is what you expected it to do?

Not knowing if it's feasible, my only thought would be to test for an ON ERROR condition while processing an ON ERROR condition and if that test is positive, bail out with an "ON ERROR loop" message.

 

[rconn]

Not knowing if it's feasible, my only thought would be to test for an ON ERROR condition while processing an ON ERROR condition and if that test is positive, bail out with an "ON ERROR loop" message.

It's not feasible. (You want an "ON ERRORERROR"?!?) It's looping at a lower level in the exception handlers; it doesn't get back to the place where the batch parser handles ON xxx conditions. And if I changed that, you couldn't get any warning about your syntax error; your batch file would just exit without explanation. (Unless you want an additional nested exception handler for every existing exception handler? That'd be a good way to slow everything down for people who are complaining that TCC is too small and running too fast on their new system ...) The best I could do would be to disable all further "ON xxx" handling while in an "ON xxx" handler. (Which would probably introduce a host of new complaints from people who are using multiple ON conditions.)

The help file does warn about the danger of your introducing errors into your error handler!

 

[vefatica]

It's not feasible. (You want an "ON ERRORERROR"?!?) It's looping at a lower level in the exception handlers; it doesn't get back to the place where the batch parser handles ON xxx conditions. And if I changed that, you couldn't get any warning about your syntax error; your batch file would just exit without explanation. (Unless you want an additional nested exception handler for every existing exception handler? That'd be a good way to slow everything down for people who are complaining that TCC is too small and running too fast on their new system ...) The best I could do would be to disable all further "ON xxx" handling while in an "ON xxx" handler. (Which would probably introduce a host of new complaints from people who are using multiple ON conditions.)

The help file does warn about the danger of your introducing errors into your error handler!

OK, but I didn't get any warning about my syntax error; the batch file just exited without explanation.

 

[rconn]

OK, but I didn't get any warning about my syntax error; the batch file just exited without explanation.

It's going to do that regardless. I can change the exception handling so it won't eat the stack when you tell it you want it to eat the stack; it should only involve a few thousand lines of code and a couple of weeks. Or you could fix your ON ERROR code, which might be somewhat faster ...