WAD ON ERROR GOTO ...

#1
See below. Depending on which "on error" statement I use, I get different results. When I use "(echo ERROR! & quit)" I see the error message. If I use "goto badip" I don't see the error message. Am I missing something?
Code:
v:\ip\test> type onerror.btm

iff "%1" EQC "foo" then
  on error (echo ERROR! & quit)
else
  on error goto badip
endiff

set ip=%@lower[%1]

do i=0 to 3
  set octet%i=%@eval[%@word[".",%i,%ip]]
enddo
echo All is OK!
quit

:badip
echo ERROR!
quit


v:\ip\test> onerror.btm foo
ERROR!

v:\ip\test> onerror.btm FOO

v:\ip\test>
 
Last edited:
#2
It seems to work fine on my machine( TCC/LE 14) Try to turn Echo on to see what is happeing. Check your aliass.

c:\>onerror.btm foo
iff "%1" EQC "foo" then
on error (echo ERROR! & quit)
set ip=foo
do i=0 to 3
set octet0=0
(echo ERROR! & quit)
ERROR!

c:\>onerror.btm FOO
iff "%1" EQC "foo" then
on error goto badip
set ip=foo
do i=0 to 3
set octet0=0
goto badip
echo ERROR!
ERROR!
quit
 
#3
It has something to do with the error occurring in a DO loop. Here's a better example.
Code:
v:\ip\test> type onerror.btm
iff "%1" EQ "1" then
  on error (echo ERROR! & quit)
else
  on error goto oops
endiff

do i=1 to 2
  BARF
enddo

echo All is OK!
quit

:oops
echo ERROR!
quit


v:\ip\test> onerror.btm 1
ERROR!

v:\ip\test> onerror.btm 0

v:\ip\test>
 
#4
Here's the last example with echo on. When the GOTO us used, the last command that's echoed os "goto oops"; what happens there isn't executed or echoed. By the way, BARF in an unknown command. No aliases look troublesome. These are the names of my aliases:
hexe e d b u @@ctrl-F10 ipblock vc8 vc10 xx f @@ctrl-o @@ctrl-u eh eini sl qt tf af cf lv: dt: ldt: predict get ncon mcon tl @@alt-f4 newbeta estart zz

Code:
v:\ip\test> type onerror.btm
@echo on
iff "%1" EQ "1" then
  on error (echo ERROR! & quit)
else
  on error goto oops
endiff

do i=1 to 2
  BARF
enddo

echo All is OK!
quit

:oops
echo ERROR!
quit


v:\ip\test> onerror.btm 1
iff "%1" EQ "1" then
on error (echo ERROR! & quit)
do i=1 to 2
BARF
(echo ERROR! & quit)
ERROR!

v:\ip\test> onerror.btm 0
iff "%1" EQ "1" then
on error goto oops
do i=1 to 2
BARF
goto oops

v:\ip\test>
 
Dec 2, 2008
212
2
Canada
#6
It doesn't work for me either, use "ON ERROR GOSUB oops" and a "return" instead of a "quit" at the end of the oops branch and it seems to work.

Here is something interesting:

I load aliases from a file and in the file is

unknown_cmd=echo What kind of command is "%$"?


When I run

onerror.btm 1

Code:
iff "%1" EQ "1" then
on error (echo ERROR! & quit)
do i=1 to 2
BARF
What kind of command is "BARF"?
BARF
What kind of command is "BARF"?
echo All is OK!
All is OK!
quit
And when running

onerror.btm 0

Code:
iff "%1" EQ "1" then
on error goto oops
do i=1 to 2
BARF
What kind of command is "BARF"?
BARF
What kind of command is "BARF"?
echo All is OK!
All is OK!
quit

Using an alias for "unknown_cmd" remove unknown commands from being an errors.
 
#8
First, randomly calling an asynchronous GOTO when you're inside a DO loop is a truly awful idea.

Second, it will work if you use the GOTO /I switch. (This is necessary so that the DO loop can clean itself up.)
I read about "/L" but it didn't seem appropriate. It "prevents GOTO from canceling IFF statements and DO loops". I'd think that would prevent the DO loop from cleaning itself up.

Anyway, I found that GOSUB works (no DO-cleanup, but it works) and has the advantage of being able to pass a message at the subroutine's argument
 

rconn

Administrator
Staff member
May 14, 2008
10,325
94
#9
I read about "/L" but it didn't seem appropriate. It "prevents GOTO from canceling IFF statements and DO loops". I'd think that would prevent the DO loop from cleaning itself up.
It would, if you were in the DO loop at the time you're doing the GOTO. But you're not -- the GOTO in the ON ERROR is happening completely independently of the DO loop, which is what causes the problem.
 
#10
It would, if you were in the DO loop at the time you're doing the GOTO. But you're not -- the GOTO in the ON ERROR is happening completely independently of the DO loop, which is what causes the problem.
Regardless of the DO loop, I'd expect "on error goto label" to do exactly that on an error, namely, goto the label and execute the commands that follow. If it isn't going to work, it should be documented. The help for "ON" mentions GOTO a few times. I don't think there are any caveats about this situation anywhere in the help.