Author |
Topic: Odd Behaviour (Read 752 times) |
|
CryptoMan
New Member
member is offline
Gender: 
Posts: 46
|
 |
Re: Odd Behaviour
« Reply #5 on: Aug 20th, 2016, 1:48pm » |
|
Why do I get an error at array index 1 in the following code?
Code:PRINT "BEFORE PARSE"
CALL ParseTLV
PRINT "AFTER PARSE"
END
SUB ParseTLV
PRINT "PARSE TLV"
CALL ZeroTAGS
PRINT "CONTINUE PARSE"
PRINT "IT CAN NOT RETURN TO MAIN LOOP"
END SUB
SUB ZeroTAGS
'ON ERROR GOTO [HANDLER]
PRINT "ZeroTAGS"
FOR i=1 TO 10
PRINT " ZT ";i;
TAGSinCard$(i)="Z"
IF Err PRINT "AFTER ERROR 1"
TAGLenCard(i)=0
IF Err PRINT "AFTER ERROR 2"
TAGValue$(i)=""
IF Err PRINT "AFTER ERROR 3"
NEXT
PRINT "END ZERO LOOP"
FOR i=1 TO 10
PRINT USING("###",i);" ";TAGSinCard$(i);" ";
IF NOT(i MOD 10) THEN PRINT
NEXT
GOTO [wait]
[HANDLER]
PRINT "Error "; Err$; " "; " code "; Err
PRINT ""
DIM TAGSinCard$(200),TAGLenCard(200),TAGValue$(200)
Err=0
RESUME
[wait]
NOTICE "WAIT"
END SUB |
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Odd Behaviour
« Reply #6 on: Aug 20th, 2016, 2:20pm » |
|
on Aug 20th, 2016, 1:35pm, CryptoMan wrote:| but this was inside a SUB and there was no local label [ERROR.HANDLER4] in that SUB. What happens in that case? Does it try to jump to the main block? |
|
Yes, in that case it will automatically exit the SUB and jump to your error handler in the main block. This should work even if an error occurs within a deeply-nested SUB: LBB should automatically 'unwind the stack' until it reaches a point where the error handler is 'in scope'.
Quote:| Please test and see the conditions below. |
|
RESUME cannot work if your error handler is in a different scope from that in which the error occurs. As I explain above, when the error happens the stack is automatically unwound until it reaches the scope containing the ON ERROR; at that point there is no way that it can 'get back to' the original scope in which the error occurred.
This is explicitly documented in the Compatibility section of the LBB help: "RESUME must be used within the scope of the SUB or FUNCTION (if any) in which the error occurred". It may be different from how LB4 behaves, but it's standard in other languages.
ON ERROR GOTO is an archaic construct prone to all sorts of problems (hardly surprising because GOTO is involved!). Consider using Structured Exception Handling (SEH) which is implemented in LBB by means of the try, catch, end try and throw statements.
on Aug 20th, 2016, 1:48pm, CryptoMan wrote:| Why do I get an error at array index 1 in the following code? |
|
It's because when LBB compiles your program it sees that you have a DIM statement for that array. It has no way of knowing that, in fact, the DIM is never executed at run-time so it doesn't fall back to the 'every array is assumed to be dimensioned with subscript 10' default.
It's (once again) called out explicitly in the LBB Help docs: "If you receive the error message 'Bad use of array' check that your program doesn't attempt to access an array before it is DIMensioned".
You might find it helpful to read through the LBB Help file.
Richard.
|
|
|
|
CryptoMan
New Member
member is offline
Gender:
Posts: 46
|
|
Re: Odd Behaviour
« Reply #7 on: Aug 21st, 2016, 4:25pm » |
|
Thanks for pointing me towards SEE.
I missed that subject and I will learn how to use it.
I have been strugling all last week and all this weekend trying to understand the logic and errors.
One issue I am having is the following. If I make a mistake and give a wrong [label], LBB does not stop and give an error pop up saying:
"Unresolved [label], execution stopped on Line XXXX" but rather wanders off to infinity and only resolution is Task Manager Kill button and at this stage I observe a CPU usage of around 30%. In normal flow this is less than 1%. Maybe it is trying to find that label beyond the limits of program code space or something you can better explain.
Another puzzling thing is Not in function at Line 0 error which is very puzzling. It succesfully compiles but then at run stage this error comes. Evidently for something like this GLOBAL p,q,r, ,x,y,z
a mistake I made when I was weeding out my code where I removed a redundant global variable and forgot to remove the comma. Instead of stopping the compilation and pointing out to line this is happening.
Maybe a two pass compilation with the first pass with stronger syntax and error checking and more clearly reporting errors and if this stage is clear than going about what is now doing could be better. As it is now, it is not very forgiving. No mercy for mistakes. And, it is really costing a lot of time trying to understand what is going on.
This is why I was looking for the old XREF software I remember from the early days of Basic listing all variables and on which lines this variable is used. Obviously one can write such a software himself but being lazy and lots of code to convert to LBB, I was wondering if somebody already knows such a tool. I noticed Notepad++ has a nice feature highlighting the variable all over the source code - not always but most of the times. That helps during this conversion.
OK. I must go back to my conversion and clean up work.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Odd Behaviour
« Reply #8 on: Aug 21st, 2016, 5:06pm » |
|
Quote:| This is why I was looking for the old XREF software I remember from the early days of Basic listing all variables and on which lines this variable is used. Obviously one can write such a software himself but being lazy and lots of code to convert to LBB, I was wondering if somebody already knows such a tool |
|
Have you tried program from reply#4 of your question on LB forum?
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Odd Behaviour
« Reply #9 on: Aug 21st, 2016, 5:16pm » |
|
on Aug 21st, 2016, 4:25pm, CryptoMan wrote:| If I make a mistake and give a wrong [label], LBB does not stop and give an error |
|
As always, I wish you would give an example! Normally LBB will report an error; try this code:
Code: goto [non.existent.label]
end
This reports (at run-time) "No such line at line 1". So if you are not receiving this error message I need to see a (preferably simple) self-contained program that demonstrates the issue.
Quote:| Evidently for something like this GLOBAL p,q,r, ,x,y,z |
|
I agree that the error message you receive in this case is less than informative! If you look at the BBC BASIC code generated it's clear why it is happening, but ideally LBB ought to report something more obvious. I'll see if there's a simple (and safe) change I could make.
Quote:| As it is now, it is not very forgiving. No mercy for mistakes. |
|
I've explained before why the error reporting is poor. It's because LBB was originally envisaged as a tool that you would use to 'boost' a program that had already been developed and tested in LB 4, therefore the expectation was that the program would not have any syntax errors. Now LBB has developed into more of a stand-alone IDE, in which you can write programs from scratch, ideally the error reporting should be better than it is.
Quote:| I was wondering if somebody already knows such a tool. |
|
There's LBReader by Jim Brossman (mknarr) which lists all the variables, arrays etc. used in a program. See this thread at the LB Community forum.
Richard.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Odd Behaviour
« Reply #10 on: Aug 21st, 2016, 6:25pm » |
|
LBReader by Jim Brossman (mknarr)
lists stuff and counts how much times it used
XREF - A LB Cross Referencer by terciops
lists lines where stuff is used.
|
|
Logged
|
|
|
|
|
