On Jun 28, 2006, at 13:01, Dark A. wrote:
trying to figure out exactly where ‘end’ needs to be in my code. I’m
using Scite and find that often time it will report ‘expecting kEND’
at the last line of the code and not where the kEND should actually
be. It would be nice if there was more accuracy but I won’t expect
it.
You shouldn’t expect it - it’s a hard thing to catch that sort of
error in a compiler or interpreter. Think of it this way:
begin
begin
begin
begin
# end <- oops!
end
end
end
The mistake is the ‘end’ commented out, but to the interpreter, the
only missing one is at the very end, since the three 'end’s that
exist match the first three 'begin’s. Because Ruby’s very liberal
when it comes to what statements you can make and where (e.g., nested
methods), it might not be clear there’s an ‘end’ missing until the
end of the file, and even then, there’s no simple way to tell which
‘end’ is actually missing, just that one is.
end # and this is the one question, but I’m guessing (i know not
good to guess) that this # one is needed for the
anotherarray loop ?
Would this be correct ? One thing I’ve found is that having the right
number of ends will make the code execute but having them in the wrong
place will have surprising results.
That’s not correct: the first end corresponds to the ‘if/else’, but
you have the other ones mixed up: the second end corresponds to
anotherarray.each, and the third one corresponds to somearray.each.
Think of it like nested boxes or Russian dolls: each begin/end block
is contained inside an outer one:
begin # 1
begin # 2
begin # 3
end # 3
end # 2
end # 1
As an interesting note, this is one of the ways in which keeping your
code indented properly makes things easier for you in the long run -
you can actually see which ‘end’ aligns to which ‘begin’. The major
benefit of proper indentation is that it makes life easier for people
on the mailing list who have to read your code.
matthew smillie.