SELECT CASE error
-
- Posts: 606
- Joined: Nov 28, 2012 1:27
- Location: CA, USA moving to WA, USA
- Contact:
SELECT CASE error
My first encounter of this error did not give me an error 62, but "error 61: Illegal inside functions ..."
I simplified until I got this correct error identification.
Because one could get a wrong error message, perhaps it should be mentioned on the wiki page that there may be no statements between the 'select case ...' statement and the first 'case x' statement. Seems obvious, but still - it happened.
In my case, it was a few lines of debugging code, easily moved somewhere else.
david
I simplified until I got this correct error identification.
Because one could get a wrong error message, perhaps it should be mentioned on the wiki page that there may be no statements between the 'select case ...' statement and the first 'case x' statement. Seems obvious, but still - it happened.
In my case, it was a few lines of debugging code, easily moved somewhere else.
david
Re: SELECT CASE error
Done:
KeyPgSelectcase → fxm [added note: No statement can be placed between the 'Select Case' statement and the first 'Case' statement]
KeyPgSelectcase → fxm [added note: No statement can be placed between the 'Select Case' statement and the first 'Case' statement]
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: SELECT CASE error
Good find. An unhelpful error message might be worthy of a bug report, rather than just a documentation note.
Re: SELECT CASE error
To be able to judge the unhelpful of the error message (61), it would be necessary to have the exact code which caused it.
This is not the first time that a (relevant) error message can hide another (equally relevant).
As for the note itself in the documentation, I do not think it is useless.
This is not the first time that a (relevant) error message can hide another (equally relevant).
As for the note itself in the documentation, I do not think it is useless.
-
- Posts: 606
- Joined: Nov 28, 2012 1:27
- Location: CA, USA moving to WA, USA
- Contact:
Re: SELECT CASE error
The note is good. Tracking down the EXACT cause not so easy.
I was calling a function in a function - with -mt
The -pp version is 2500 lines, with a LOT of precompiled static libs. Not so easy to get back to that same faulty error.
Also, I still get from time-to-time the console close failure where FB threads don't reset the console (Linux) correctly before stopping the program.
A segfault happens somewhere that has been very hard to pinpoint. (The program just closes somewhere in the destructors; only gdb reports the segfault.) So, the trigger for that incorrect error message could be a number of things.
Puzzling at first, but the line number was correct, so it only took me a few minutes to arrive at the correct error, so no problem. If it shows up again I will be more sensitive to the conditions and try a little more to catch the circumstances.
david
I was calling a function in a function - with -mt
The -pp version is 2500 lines, with a LOT of precompiled static libs. Not so easy to get back to that same faulty error.
Also, I still get from time-to-time the console close failure where FB threads don't reset the console (Linux) correctly before stopping the program.
A segfault happens somewhere that has been very hard to pinpoint. (The program just closes somewhere in the destructors; only gdb reports the segfault.) So, the trigger for that incorrect error message could be a number of things.
Puzzling at first, but the line number was correct, so it only took me a few minutes to arrive at the correct error, so no problem. If it shows up again I will be more sensitive to the conditions and try a little more to catch the circumstances.
david
Re: SELECT CASE error
Changed in fbc-1.09, I tried to improve the error message:
Different error messages were being shown depending on if the SELECT was module level scope or procedure level scope.
If still missing the appropriate error message, please post a short code to show the problem.
Code: Select all
'' bad-stmt.bas
sub bad_select()
dim x as integer = 1
select case x
print "oh no!"
case 1
print "1"
end select
end sub
/'
FBC OUTPUT:
bad-stmt.bas(6) error 62: Statement in between SELECT and first CASE, found 'print' in 'print "oh no!"'
'/
If still missing the appropriate error message, please post a short code to show the problem.
Re: SELECT CASE error
Well found !
Re: SELECT CASE error
Code: Select all
sub selector()
const x as integer = 122
select case x
const a=asc("z")
const z= "oh no!"
case a
print z
end select
end sub
selector()
sleep
Re: SELECT CASE error
@dodicat, interesting.
Appears to have been allowed for CONST and ENUM because neither generate code (only a symbol addition to the local scope) and SELECT CASE begins a new SCOPE. I can't imagine any user code in the wild depending on that. I'll add a couple of extra checks to CONST and ENUM to generate an error. Thanks.
Appears to have been allowed for CONST and ENUM because neither generate code (only a symbol addition to the local scope) and SELECT CASE begins a new SCOPE. I can't imagine any user code in the wild depending on that. I'll add a couple of extra checks to CONST and ENUM to generate an error. Thanks.
Re: SELECT CASE error
You can also have labels: (which work).
You can exit select there, and if the select case is in a sub/function you can have exit sub/function in there as well.
I would say that between constants, enums, the exit statements and labels you would have a hard job actually finding the first case after select case, if you so desired of course.
You can exit select there, and if the select case is in a sub/function you can have exit sub/function in there as well.
I would say that between constants, enums, the exit statements and labels you would have a hard job actually finding the first case after select case, if you so desired of course.
Re: SELECT CASE error
I appreciate the testing and feedback. Helps provide some polish to the compiler.dodicat wrote:You can also have labels: (which work).
You can exit select there, and if the select case is in a sub/function you can have exit sub/function in there as well.
I've add the checks for labels and EXIT statements to generate an error between SELECT CASE and first CASE statement. I can't think of a use case where this makes sense to allow.
For anyone that is curious, what makes me nervous about this kind of change is that in a recursive descent parser is that there are many code paths to get to the same place in the parser's execution and the default tends to be that everything is permitted unless explicitly checked. I've added an explicit check to error for certain statements based on context. And because the test-suite is not exhaustive in proving out every scenario where labels, EXIT's, CONST's etc, should be allowed, there is the risk I've made a mistake and suddenly valid code no longer compiles. I don't think so ... but I look forward to the bug reports if a mistake has been made.