Yes, you're right... But we were using return to show explicitly a "stop" in
the prorgram.
We are using javascript to define execution paths in a online surveys
application. Our users are not expert programmers. We are using return in
the top-level program to:
1. stop the survey
2. stop the survey and redirect to an external application url
In the surveys industry is very common to have some filter questions to stop
a non-interesting respondent to keep responding, so a typical flow is to
filter the user at the beginning, for example:
// ask respondent for his age and sex
if (age < 18) {
return "http://notinteresting.html";
}
// keep the survey
If we cannot use "return" then we force the survey writter to keep all the
nested if structures (which can be quite impressive) like this:
// ask respondent for his age and sex
if (age < 18) {
"http://notinteresting.html";
} else {
if (...) {
} else {
../..
}
}
At the same time, I think it can be a little strange for a survey programmer
to have expression statements, like the one on previous example, to indicate
the redirect... And perhaps is yet more strange to have branches with no
statements at all to simulate the return with no parameters (which has a
specific default meaning in our app).
However, the parser is right and all this is another problem and we will
have to think what to do. Thanks for your answer Attila.
Iván
El 26 de julio de 2010 12:34, Attila Szegedi <[email protected]> escribió:
> However, the return value of the top-level program is the value of the last
> expression statement that was evaluated. So if you simply omitted every
> "return" keyword in there, you'd end up with a semantically identical, yet
> syntactically valid program :-)
>
> Attila.
>
> On 2010.07.26., at 12:29, Iván Párraga García wrote:
>
> > Hi,
> >
> > I was wrong... In 12.9 section in ECMAScript-262 spec can be read:
> >
> > "An ECMAScript program is considered syntactically incorrect if it
> contains
> > a return statement that is not within a FunctionBody"
> >
> > Ok... I'll try to find a workaround or to anlyze if we're abusing the use
> of
> > "return" in our application.
> >
> > Cheers,
> >
> > Iván
> >
> >
> > El 26 de julio de 2010 11:36, Iván Párraga García <
> > [email protected]> escribió:
> >
> >> Hi,
> >>
> >> I'm embedding Rhino parser within our application and I've found the
> >> following problem: the parser throws a "invalid return" parse exception
> when
> >> the return statement is in the top scope (outside any function). For
> >> example, the following javascript program provokes 3 errors.
> >>
> >> var b = true;
> >> if(b) {
> >> return
> >> } else if (b<0) {
> >> return 5
> >> } else {
> >> return "bye"
> >> }
> >>
> >> If I'm not wrong, previous script is a valid Ecma program and our
> >> application uses this construct so I need to be able to parse it.
> >>
> >> Am I doing something wrongly? Do I need to set up some flag on the
> parser?
> >>
> >> Cheers,
> >>
> >> Iván
>
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
