Announcement

**Paul Dixon** · 19 Feb 2008, 07:26 PM

Cliff,

but wondered if PB allows a "ON <Insert Value> GOTO/GOSUB"?

PB has ON..GOTO and ON..GOSUB statements which, as far as I know, do the same thing those statements did on DOS BASICs.

ON ERROR is a different type of command as the jump to the specified error handler takes place when the error occurs and not when the ON ERROR statement is encountered.

Paul.

**Rodney Hicks** · 19 Feb 2008, 09:29 PM

Paul is right and you can access the ON GOSUB/GOTO with the following, depending on how many errors you're planning on making.

Code:

ON ERROR GOSUB uhoh
....
your error filled code here
...
ON myerror GOSUB badmove, worsemove, ...
uhoh:
if err=53 then 
  myerror =1
elseif err=72 then
myerror =2
...
end if
RETURN
badmove:
blah, blah, etc
RETURN
worsemove:
&*^%% @@
RETURN

Of course, the subroutines could be accessed straight from the IF block.

Rod.

**Michael Mattias** · 20 Feb 2008, 07:28 AM

>ON ERROR GOSUB uhoh

Thre is no such thing as ON ERROR GOSUB (in 8.03 help file).

There is ON ERROR GOTO.

Doesn't make sense to have ON ERROR GOSUB when you think about it... since you must return from an error handler with RESUME anyway.

MCM

**Rodney Hicks** · 20 Feb 2008, 07:57 AM

You're right Michael.
I was concentrating on the ON x GOSUB and didn't even look at the ON ERROR syntax or think about it much.
The point is pretty much the same though with a little adjustment if that is the direction he wants to go. As long as he takes care with the placement of the label (without the RETURN I associated with the goto label).

I guess 'uhoh' was a good label for it.

Rod

**Michael Mattias** · 20 Feb 2008, 08:04 AM

FWIW, you can force your code to branch to an error handler based on application conditions....

Code:

%MYERROR = (any value between 151 and 240)

  ON ERROR GOTO MyErrorTrap
  yadda, yadda
  IF Condition THEN
      ERROR   %MYERROR
     .....


MyErrorTrap:
  WhatEver
  RESUME somewhere

I "think" you can also use ERROR to set the system ERR variable if you are checking ERR in-line rather than using ON ERROR GOTO. I never tried this myself, but it just might work.

**Cliff Nichols** · 20 Feb 2008, 06:27 PM

Actually I was more looking at

Code:

%MyERROR = 42     'And yes I chose that value on purpose if you get the joke
ON %MyERROR GOTO <Insert Error Handler>

In a few (not many) but few cases, it would be nice to build a stronger error handling routine geared more toward the purpose of the program rather than the cryptic answers the user would get.

For that matter, can I also use

Code:

%MyERROR = 42     'And yes I chose that value on purpose if you get the joke
ON ERROR GOTO <Insert Error Handler>
ON %MyERROR GOTO <Insert Error Handler>

in combination? (I suppose I could try and work up an example test using)

Code:

ON ERROR GOTO <Insert Error Handler>
ON ERR GOTO <Insert Error Handler>

and see if that works as well for a beginning test

**Rodney Hicks** · 21 Feb 2008, 12:46 AM

You might try:

Code:

IF ERR THEN GOTO label

That would send any error to the goto, and gosub would work as well.

Rod

**Bryan Flick** · 21 Feb 2008, 01:40 AM

FWIW, you can force your code to branch to an error handler based on application conditions....

Code:

%MYERROR = (any value between 151 and 240)

  ON ERROR GOTO MyErrorTrap
  yadda, yadda
  IF Condition THEN
      ERROR   %MYERROR
     .....


MyErrorTrap:
  WhatEver
  RESUME somewhere

That's a pretty neat way to handle errors. Is there a performance hit for using ON ERROR GOTO? The documentation didn't mention any.

Thanks,
Flick

https://www.globalheavyindustries.com

**Bob Zale** · 21 Feb 2008, 05:26 AM

There is no real performance hit from ON ERROR GOTO. The executable will be a bit larger, but it's surely not significant. Highly recommended where appropriate.

Happy coding! {smile}

Bob Zale
PowerBASIC Inc.

**Michael Mattias** · 21 Feb 2008, 08:32 AM

Code:

IF ERR THEN GOTO label

If you use this (or 'IF ERR THEN GOSUB subname') I think I'd suggest using ERRCLEAR so you don't forget to reset the ERR variable.

eg ....

Code:

E = ERRCLEAR: IF E THEN GOSUB Label

... which you 'could' put into a MACRO to save some typing...

Code:

MACRO CheckErr
  E = ERRCLEAR
  IF E THEN GOSUB LABEL
END MACRO 
....
....
     Important code here 
     CheckErr 
     more important code here
....

(In my code, "E" is always the most recent PB error, and 'LE' the most recent WinApiError from GetLastError()).

MCM

**Rodney Hicks** · 21 Feb 2008, 10:05 AM

For that matter, can I also use
Code:

%MyERROR = 42 'And yes I chose that value on purpose if you get the joke
ON ERROR GOTO <Insert Error Handler>
ON %MyERROR GOTO <Insert Error Handler>

in combination? (I suppose I could try and work up an example test using)
Code:

ON ERROR GOTO <Insert Error Handler>
ON ERR GOTO <Insert Error Handler>

and see if that works as well for a beginning test

The ON ERR GOTO can only be made to work for 255 errors. To get to error=42 label you need 42 labels.

Yes ERRCLEAR makes sense to me as well. The macro could be used to expand the error message as well, since I believe that's his purpose.

**Cliff Nichols** · 21 Feb 2008, 06:26 PM

Funny how the "ON ERROR" replies, I was looking at "ON 42" type for errors not caught at runtime

I like Bob's post of how the performance hit is not much at all (as is with most performance hit questions, but I am not worried about that at the moment, just if I can do it?)

MCM's MACRO idea I started implementing a while back while developing my latest-greatest, just so I could see how much time saving it would give me to not add multiple lines of error-checking, and use 1 macro (saves on file size a bit, but considering the size, the biggest time saver is to add 1 or 2 lines of code to each function vs 12 or more, on the "OFF-CHANCE" an error occurs that I had not thought of when I coded it, but a user may have caused it, so I can check a log and see as close as I can what may have caused it at that moment in time)

From time to time I get an error not caught until I can replicate it, (and do NOT give me the ole "Before you can code it, how can you break it?" train of thought because I may get lazy from time to time, or just not fully understand the concept, but I am always willing to go back and see if I can break my code)

I can easily use "ON ERROR" but for those lil things that slip through, can I use "ON MYERROR"?
(Its a matter of Symantecs at this point, but thought I would ask)

**Michael Mattias** · 22 Feb 2008, 08:15 AM

>can I use "ON MYERROR"?

???????

"ON <constant> GOTO somewhere" makes no sense.

Just trap your error and eschew processing others...

Code:

%MYERROR = anyvalue

ON ERROR GOTO Mytrap

...

MyTrap:
  IF ERR = %MYERROR THEN
     do something
    RESUME somewhere
  ELSE
    do nothing 
    RESUME somewhere_else
 END IF

MCM

**Cliff Nichols** · 22 Feb 2008, 06:15 PM

"ON <constant> GOTO somewhere" makes no sense.

Makes perfect sense, but maybe I am not explaining correctly.

ERROR must be defined as some value
ERR must be defined as some value

I was looking at API functions that either return a handle, or 0 if error (compiler does not catch these because technically it is not an error per say (and I think I know why) but I was hoping to use built in functions of the compiler in functions that I can expect a value that is an error, but NOT an error to the compiler, just my making mistakes.

stuff like
ON 0 GOTO ErrHandler

could be done using macros to check the reply of each api call, but wanted to ask if already proven you can not ON 0 GOTO ErrHandler
but can macro to do the same?

I guess my only real answer is...."Try it" if you like it, then "Test it", and try to share what I learned for others that may wonder the same thing in the future.

**Michael Mattias** · 23 Feb 2008, 07:25 AM

ON variable makes sense.

ON constant does not.

**Cliff Nichols** · 24 Feb 2008, 06:09 PM

My appologies

Sorry guys, I wasted a ton of time and and instead should have just taken 42 seconds to do a simple test.

Code:

#COMPILE EXE
#DIM ALL
#INCLUDE "Win32Api.inc"
FUNCTION PBMAIN () AS LONG
     LOCAL MyError AS DWORD
     ON MyError GOTO ErrHandler
     MyError = %INVALID_HANDLE_VALUE         'Doesn't do it
     SetLastError MyError                    'Nope still doesn't do it
     MSGBOX "Answer found, you cant do a a custom ON ERROR concept"
     EXIT FUNCTION
ErrHandler:
     MSGBOX "Error Raised"
END FUNCTION

Answer found

I will chalk it up to "Programmer stress to get everything done, and not enough time to do half of it."

**Gösta H. Lovgren-2** · 24 Feb 2008, 08:35 PM

Cliff, Dunno if this is what you're looking for but here's a Macro I have found very handy:

Code:

'
Macro m_Err_Msg 
 If Err Then 
    Stile = %MB_SYSTEMMODAL Or _          
            %MB_ICONERROR Or _
            %MB_ICONWARNING  
 
   ? m$ & $CrLf & $CrLf & _           
     m1$ & $CrLf & $CrLf & _           
     Using$("# ", Err) & Error$(Err),_
     Stile, _
     " In " & FuncName$ 
     ErrClear
 End If 
 Reset m$, m1$ 
End Macro 
'

Obviously have to Declare m$ & m1$ for custom msgs. Also ditto Stile (or just skip it using it and put the Styles in the msgbox. Double ditto m$'s)

=============================
O white and midnight sky,
O starry bath,
Wash me in thy pure,
heavenly crystal flood:
Cleanse me, ye stars,
from earthly soil and scath—
Let not one taint remain
in spirit or blood!
Richard Watson Gilder
=============================

**Robert DeBolt** · 25 Feb 2008, 07:12 PM

Try/catch/finally/end Try

Code:

'  OnError.bas
'
#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
    LOCAL MyERR AS LONG
    LOCAL MyStr AS STRING
 
    TRY
        OPEN "OnError.txt" FOR INPUT ACCESS READ AS #1
        LINE INPUT #1, MyStr
        MSGBOX MyStr
        CLOSE #1
    CATCH
        MyERR = ERRCLEAR
        MSGBOX "Caught error: " & STR$(MyERR) & $CRLF & ERROR$(MyERR)
    FINALLY
        MSGBOX "End of program"
    END TRY
 
END FUNCTION

Announcement

ON ERROR equiv "ON VALUE"?

ON ERROR equiv "ON VALUE"?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment