I'm getting an error on compiling that I can't understand:
error 48: Undefined label, _0_a On Line:
No line number, and have no idea what the _0_ is about.
Can't find anything in the forum. One note -- I do have -ex
set on the compiler options because I have some ON ERROR
handling with RESUME's in the code.
It compiles with PDS (except I have line numbers after the
resumes).
:???:
Dean
post the erronous code itself as well -we can't predict from air what's ousing problems
I'll post it as soon as I clean it up a little bit. :oops:
I was just asking first of all what is Error 48 supposed to mean.
Is there a table of errors somewhere in the DOCs?
Dean
I figured out that the FB error results from my using the
ON ERROR GOTO 0 statement which is how QB disables
error handling.
I guess there's no line 0, so it's complaining about an undefined
label. I don't find anything in the fb keywords or on the forum
(although I only spent 10 mins) as to any differences with FB on
disabling error handling. Here's just an example to reproduce
the error I'm getting in FB, but it compiles in QB:
ON ERROR GOTO Error.Handling
OPEN "Test.Dat" FOR BINARY ACCESS READ WRITE SHARED AS # 1
ON ERROR GOTO 0
CLOSE #1
END
Error.Handling:
RESUME
PRINT "Error Opening File."
CLOSE #1
END
You cant disable error handling in FB.
It was discussed long time ago..
The ugly ON [LOCAL] ERROR GOTO 0 was added to 0.13.
Yeah, works with 0.13. I was using version 0.11. Thanks!
But, don't know what the rag is on using it.
Why is it
UGLY? It is a pain in the butt to deal with, but
what alternatives are there? Is there a better technique that I
should be using to handle errors that wouldn't involve disabling
error handling?
Otherwise, as I see it, every error would take you to the same
label, and you would then have to figure out where the error
originated anywhere in your code, handle the error, and somehow
return from this one error handling label to potentially anywhere in
your code to continue, unless you just want to end the program.
If there's a cleaner way to manage errors, I'd appreciate some
suggestions.
Dean
Personal opinion.. QB error handling is too clumsy, if statements weren't so many (ie, if they were ordinary functions) and if weird syntaxes weren't used, no error handlers of this type would be needed.
OPEN, CLOSE, GET, PUT can be used as functions in 0.13, if the return value is 0, no errors happened, otherwise it's a runtime error.. "if OPEN( filename, for input, as #1 ) <> 0 then reporterror FILENOTFOUND" etc
Could a special FBERRORCODE value be added to the compiler that holds the last error generated? Then if the programmer wanted to use it for non-function statements it could just be checked at each call?
BLOAD "image.bmp"
IF FBERRORCODE <> 0 THEN
' error roporting
END IF
steven_basic: I totaly agree! Then fb would be compatible with qbs error handling and have its own improved errorhandling.