Coruption after which BTMs won't run

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
The first line of this BTMfile has an error; @LINE's parameters are reversed.
Code:
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.
Code:
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:
Code:
 Fault Module Name:    IDE.EXE
  Exception Code:    c0000005
  Exception Offset:    000127e6
 
#5
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

Administrator
Staff member
May 14, 2008
10,100
85
#6
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!
 
#7
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

Administrator
Staff member
May 14, 2008
10,100
85
#8
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 ...