nesting functions

[Philip WATTS]

I am trying to carry out multiple checks on some input data. I am doing this
by the running the data through a number of functions. i.e. I have an
onclick that calls a function, which in turn calls the test functions.

My problem is getting the testing to stop if one of the tests fails and
await for the input to be amended.
I believe that this is because the when the testing function has finished it
returns the script to the point immediately AFTER the function was called,
i.e. it simply carries on to the next test and hence to completetion of the
script.

How do I overcome this problem?

Many thanks
Phil

[e]

Have each function return a boolean indicating it's success. Sorry js isn't
my forte I'm just lurnking while I wait for an answer to one of my posts :p,
so syntax could be way off. But general idea is this:

function checkTheInput()
{
if (firstCheck())
{
if (secondCheck())
{
if (thirdCheck())
{
alert('all 3 cheks were ok');
}
else
{
alert('thirdCheck() failed');
}
}
else
{
alert('secondCheck() failed');
}
{
else
{
alert('firstCheck() failed');
}
}

function firstCheck()
{
//if data is ok return true, otherwise return false
}

function secondCheck()
{
//ditto
}

etc...

"Philip WATTS" <PR*****@syringa.freeserve.co.uk> wrote in message
news:bn**********@news8.svr.pol.co.uk...

I am trying to carry out multiple checks on some input data. I am doing this by the running the data through a number of functions. i.e. I have an
onclick that calls a function, which in turn calls the test functions.

My problem is getting the testing to stop if one of the tests fails and
await for the input to be amended.
I believe that this is because the when the testing function has finished it returns the script to the point immediately AFTER the function was called,
i.e. it simply carries on to the next test and hence to completetion of the script.

How do I overcome this problem?

Many thanks
Phil

[Douglas Crockford]

> I am trying to carry out multiple checks on some input data. I am doing this

by the running the data through a number of functions. i.e. I have an
onclick that calls a function, which in turn calls the test functions.

My problem is getting the testing to stop if one of the tests fails and
await for the input to be amended.
I believe that this is because the when the testing function has finished it
returns the script to the point immediately AFTER the function was called,
i.e. it simply carries on to the next test and hence to completetion of the
script.

How do I overcome this problem?

Have each function return true if the input is ok. Then use if statements.
if (test1()) {
if (test2()) {
if (test3()) {
...

http://www.crockford.com/#javascript

[Thomas 'PointedEars' Lahn]

Philip WATTS wrote:

My problem is getting the testing to stop if one of the tests fails and
await for the input to be amended.
I believe that this is because the when the testing function has finished it
returns the script to the point immediately AFTER the function was called,
i.e. it simply carries on to the next test and hence to completetion of the
script.

How do I overcome this problem?

Instead of using nested if-statements you could simply `return false'
if a check fails. I find this more practical since you can add tests
without further nested block statements (and without indentation which
should have been done then for the sake of legibility):

function testMe()
{
if (!test1())
return false;
if (!test2())
return false;
if (!test3())
return false;

return true; // passed all tests
}
PointedEars

[Lasse Reichstein Nielsen]

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

function testMe()
{
if (!test1())
return false;
if (!test2())
return false;
if (!test3())
return false;

return true; // passed all tests
}

That sounds like a job for short-circuit boolean operators!

function testMe() {
return test1() && test2() && test3();
}

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Thomas 'PointedEars' Lahn]

Lasse Reichstein Nielsen wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

function testMe()
{
if (!test1())
return false;
if (!test2())
return false;
if (!test3())
return false;

return true; // passed all tests
}

That sounds like a job for short-circuit boolean operators!

function testMe() {
return test1() && test2() && test3();
}

Not if you, like the OP, want to know *which*
test failed (which I omitted in the above code):

function ...(...)
{
if (!test1())
alert("Test 1 failed!");
return false;
}
...
return true; // passed all tests
}
PointedEars

[Evertjan.]

Thomas 'PointedEars' Lahn wrote on 01 nov 2003 in comp.lang.javascript:

Not if you, like the OP, want to know *which*
test failed (which I omitted in the above code):

function ...(...)
{
if (!test1())
alert("Test 1 failed!");
return false;
}
...
return true; // passed all tests
}

Thet you should put an extra { where it belongs:

function testing() {
if !test1() {
alert("Test 1 failed!");
return false;
}
...
alert("passed all tests");
return true;
}

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Grant Wagner]

Thomas 'PointedEars' Lahn wrote:

Philip WATTS wrote:

My problem is getting the testing to stop if one of the tests fails and
await for the input to be amended.
I believe that this is because the when the testing function has finished it
returns the script to the point immediately AFTER the function was called,
i.e. it simply carries on to the next test and hence to completetion of the
script.

How do I overcome this problem?

Instead of using nested if-statements you could simply `return false'
if a check fails. I find this more practical since you can add tests
without further nested block statements (and without indentation which
should have been done then for the sake of legibility):

function testMe()
{
if (!test1())
return false;
if (!test2())
return false;
if (!test3())
return false;

return true; // passed all tests
}

PointedEars

This is known as a "gauntlet" <url: http://mindprod.com/jgloss/gauntlet.html />,
specfically an "Early Return Style Gauntlet".

I used to detest this type of code, it seemed sloppy and ugly, however, as I write
more and more code, I find myself using the style more and more often, because as
Roedy points out "I like this style because the conditions are independent and
uniform. You can shuffle the order easily and add new conditions without having
the adjust the existing code.".

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html

[Thomas 'PointedEars' Lahn]

Evertjan. wrote:

Thomas 'PointedEars' Lahn wrote [...]:

Not if you, like the OP, want to know *which*
test failed (which I omitted in the above code):

function ...(...)
{
if (!test1())
alert("Test 1 failed!");
return false;
}
...
return true; // passed all tests
}

Thet you should put an extra { where it belongs:

function testing() {
if !test1() {

Also nitpicking, the `if' statement requires
parantheses around the conditional expression.
PointedEars

[Evertjan.]

Thomas 'PointedEars' Lahn wrote on 23 nov 2003 in comp.lang.javascript:

Thet you should put an extra { where it belongs:

function testing() {
if !test1() {

Also nitpicking, the `if' statement requires
parantheses around the conditional expression.

Pick nit and be my guest ;-)

"requires" by definition or by erroring out ?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Lasse Reichstein Nielsen]

"Evertjan." <ex**************@interxnl.net> writes:

Thomas 'PointedEars' Lahn wrote on 23 nov 2003 in comp.lang.javascript:

Also nitpicking, the `if' statement requires
parantheses around the conditional expression.

"requires" by definition or by erroring out ?

Requres by the syntax rules of Java/ECMAScript. Without them, it
is not an if statement, just a syntax error.

(I don't know what "erroring out" means).

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Evertjan.]

Lasse Reichstein Nielsen wrote on 23 nov 2003 in comp.lang.javascript:

"Evertjan." <ex**************@interxnl.net> writes:

Thomas 'PointedEars' Lahn wrote on 23 nov 2003 in comp.lang.javascript:

Also nitpicking, the `if' statement requires
parantheses around the conditional expression.

"requires" by definition or by erroring out ?

Requres by the syntax rules of Java/ECMAScript. Without them, it
is not an if statement, just a syntax error.

Since when is a statement not a statement if the subsequent syntax is not
according to the rule book? In your definition, which is not mine, a
statement can never be syntactically incorrect, it seems.
(I don't know what "erroring out" means).

Does it give an error or does it work as intended [by me and anyone
reasonable]? There is a big difference between syntactical correctness and
a working script, in both possible scenarios: Some syntactical incorrect
scripting works, some syntactical correct scripting doesn't and then you
get an error, a crash or an unforseen and inintended result. In those two
circumstances it the working incorrect script seems preferable.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Lasse Reichstein Nielsen]

"Evertjan." <ex**************@interxnl.net> writes:

Since when is a statement not a statement if the subsequent syntax is not
according to the rule book?
What do you mean by "subsequent"?

The syntax of an "if" statement is:
keyword "id"
left parenthesis, "("
expression
right parenthesis, ")"
statement
(optional: keyword "else" + statement)

Omitting the parentheses makes it no more an "if" statement that
omitting "function" makes something a function declaration.
In your definition, which is not mine, a
statement can never be syntactically incorrect, it seems.
Exactly.
In fact, if the syntax is incorrect, not only isn't it a statment,
it's not even Javascript (or maybe more correct, not even ECMAScript,
since Javascript doesn't have as exact a definition).

A syntax error is just that: an error. It might have been intended
to be a statement, but it isn't.

(I don't know what "erroring out" means).

Does it give an error or does it work as intended [by me and anyone
reasonable]?

It gives an error. It fails to compile correctly, which also means
that the entire file/script element it is in, is ignored.
There is a big difference between syntactical correctness and
a working script, in both possible scenarios: Some syntactical incorrect
scripting works,
Correct. Some interpreters allow things not in the official syntax,
like function declarations inside block statements or <!-- for comments.

This is not one of those. You can no more omit the parenteses of an
if expression than you can those of a while, switch or for expression.
some syntactical correct scripting doesn't and then you
get an error, a crash or an unforseen and inintended result.
That would be a runtime error, e.g., accessing a property of the null
value.
In those two circumstances it the working incorrect script seems
preferable.

Not working at all is preferable to working incorrectly. :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Evertjan.]

Lasse Reichstein Nielsen wrote on 23 nov 2003 in comp.lang.javascript:

In those two circumstances it the working incorrect script seems
preferable.

Not working at all is preferable to working incorrectly. :)

You misread my point.

No, no, an incorrect (specs wise) script could work as intended.

And a correct (specs wise) script could work incorrectly.

An example comes to mind: the Jscript toFixed().
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)