javascript cause itself to stop ?

[Eric Osman]

My javascript program has reason to want to stop.

For example, function A has 5 lines, the second of which calls function
B, which has 5 lines, the first of which calls function C.

But function C discovers that something is very wrong so it does an
"alert" saying something like

Sorry, couldn't make the necessary connection

At this point, I want the program to STOP rather than returning to
function B.

What can I put in function C after the "alert" to make it STOP completely ?

It's too cumbersome to have to put a special check into function B to
make sure that function C was able to make the required connection (not
to mention function C having to communicate this to function B), plus
having to then also put similar verification into function A etc etc.

It's much easier if I can have functions A and B *assume* that function
C successfully made the connection, and in turn function C causes a real
STOP if it can't make the connection.

In case you're wondering how global a STOP I'm talking about, since
clearly I don't want the entire web browser to stop, let alone the
entire machine (ha ha), notice what happens when a syntax error is
encountered in the middle of a javascript. The browser manages to STOP
the javascript after displaying the error. It's that kind of a STOP I'm
looking for.

(in fact, I was tempted to implement my STOP in a very ugly way, by
intentionally doing some sort of "eval" of a syntactically bogus string,
but I didn't try this yet)

er*******@rcn.com 2-Mar-2004

[Lee]

Eric Osman said:

My javascript program has reason to want to stop.

For example, function A has 5 lines, the second of which calls function
B, which has 5 lines, the first of which calls function C.

But function C discovers that something is very wrong so it does an
"alert" saying something like

Sorry, couldn't make the necessary connection

At this point, I want the program to STOP rather than returning to
function B.

What can I put in function C after the "alert" to make it STOP completely ?

It's too cumbersome to have to put a special check into function B to
make sure that function C was able to make the required connection (not
to mention function C having to communicate this to function B), plus
having to then also put similar verification into function A etc etc.
That's how professionals generally write code. Function C should return
a status code (possibly just true or false) indicating success.

If you're sure that your users have modern browsers, you could also
look into "throw"-ing an exception, but that could be even more
trouble than returning a status code, if you also plan to "catch"
the exception.
(in fact, I was tempted to implement my STOP in a very ugly way, by
intentionally doing some sort of "eval" of a syntactically bogus string,
but I didn't try this yet)

Note that this would disable all Javascript in the page, preventing them
from just trying again, etc.

I once evaluated commercial code that responded to any error condition
by calling an "abort" function that simply divided by zero. We didn't
buy it.

[Eric Osman]

>>It's too cumbersome to have to put a special check into function B to

make sure that function C was able to make the required connection (not
to mention function C having to communicate this to function B), plus
having to then also put similar verification into function A etc etc.

That's how professionals generally write code. Function C should return
a status code (possibly just true or false) indicating success.

Let me put it another way then.

Suppose function A calls function B calls function C .

In fact, fuction A calls functions D, E, and F, all of which also call C.

In the original version of function C, it returns a string. It was
never believed to ever fail.

Now, in version 2, we realize that there is a condition under which
function C can't return its string , and we do not intend to provide
recovery for this situation. We only want to put up a message that says

Sorry, please try again during business hours

and then stop.

If we have to redesign function C to return a status code, then we have
to return the string elsewhere. Sure, there are ways to do this, like
return an object that contains both a status code and a string.

But look at all the extra stuff we have to do ! We have to recode
functions A, B, D, E, and F .

Such a recode could be considered warranted if we're enhancing the
product to include some sort of recovery .

But in our example, we don't intend to do any kind of recovery , so the
recoding of all those routines would look something like this:

old code:

function B() {
var str = C();
do stuff
}

new code:

function B() {
var obj = C();
var str;
if (obj.status) {
str = obj.str;
do stuff
}
}
What a pain. I really do think this would be an example in which a
"stop" routine (to be called from function C) would be appropriate
instead of requiring all the recoding.

er*******@rcn.com

[Lasse Reichstein Nielsen]

Eric Osman <er*******@rcn.com> writes:

What a pain. I really do think this would be an example in which a
"stop" routine (to be called from function C) would be appropriate
instead of requiring all the recoding.

That's what exceptions are for! Nobody will add a "stop" function
when they can just do:

throw "Try again during business hours!";

and even add
try {
... B() ... D() ... E() ... F() ....
} catch (error) {
alert(error);
}
around the body of function A.

The browsers that doesn't support "throw" (IE 4, NS 4, or
contemporaries) are unlikely to be extended with a "stop" function
anyway.

/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.'

[Lee]

Eric Osman said:

It's too cumbersome to have to put a special check into function B to
make sure that function C was able to make the required connection (not
to mention function C having to communicate this to function B), plus
having to then also put similar verification into function A etc etc.

That's how professionals generally write code. Function C should return
a status code (possibly just true or false) indicating success.

If we have to redesign function C to return a status code, then we have
to return the string elsewhere. Sure, there are ways to do this, like
return an object that contains both a status code and a string.

Not at all. On failure, you have it return a special string
that can't be confused with a valid return value, typically
an empty string.

[Eric Osman]

Lee wrote:

Eric Osman said:

It's too cumbersome to have to put a special check into function B to
make sure that function C was able to make the required connection (not
to mention function C having to communicate this to function B), plus
having to then also put similar verification into function A etc etc.
That's how professionals generally write code. Function C should return
a status code (possibly just true or false) indicating success.

If we have to redesign function C to return a status code, then we have
to return the string elsewhere. Sure, there are ways to do this, like
return an object that contains both a status code and a string.

Not at all. On failure, you have it return a special string
that can't be confused with a valid return value, typically
an empty string.

Not sufficient. Routine C could be modified to return an empty string,
but then routine B needs to be taught to check for it, and then routine
B has to be redesigned (we didn't even discuss what routine B was
returning) and then all the calls to routine B have to be redesigned.

In other cases the situation could be even different. For example,
consider a routine C that is supposed to allocate a global array of
100000 elements, something like

for (var i=0; i<100000; i++)
someGlobalArray[i] = ...

This routine C doesn't return anything, and hence all the callers to it
don't check for any return value.

Similarly, in this new example, let's say routine B doesn't return any
value either, so none of the calls to B ever check for one.
Let's say the system is low on memory, so that somewhere during that
"for" loop, javascript can't expand the array.

Presumably, javascript puts up some sort of "out of memory" error box in
this case, and I'd bet javascript knows how to STOP rather than allowing
routine C to continue running.

So I'm merely asking how one would implement a similar kind of STOP to
those that javascript presumably already knows how to do.

Hmmm, is there a "throw" in javascript ? Maybe some condition can be
"thrown" to cause the stop ?

[Nathan Sweet]

Lee <RE**************@cox.net> wrote in message news:<c2********@drn.newsguy.com>...

Not at all. On failure, you have it return a special string
that can't be confused with a valid return value, typically
an empty string.

Or return null. If returning null already has a special meaning to
existing code, then would I suggest a special string. Of course this
still requires editing existing code, which is just how things work.
There is no way to stop execution of a thread, short of causing a
javascript error. This is a very hacky way of doing it because you
have to cause a specific error and then assume any time that error
occurs, it is because you caused it on purpose. If the error occurs as
a genuine error, it will be thrown away. Check out my code below. The
onerror handler is set right before the error is caused, and then
removed right away. It is possible another thread could cause this
same error within this time, but if we are going to implement a hack,
we should make it least likely as possible that it could malfunction.
This code is IE 5.5+ specific, but is just meant as an example anyway.
Try it out...

alert( "before" );
stop();
alert( "after" );

function stop () {
window.onerror = handleError;
new Number().toExponential( -1 );
}

function handleError ( errorMessage ) {
window.onerror = null;
if ( errorMessage == "The number of fractional digits is out of
range" ) return true;
}

[Andrew Urquhart]

Eric Osman wrote:

Hmmm, is there a "throw" in javascript ? Maybe some condition can be
"thrown" to cause the stop ?

If you can guarantee a javascript version that supports exceptions in
the users environment then go ahead. I write a lot of server-side
"Javascript" so I know I can make such a guarantee, here's a contrived
example (not tested, but you get the idea!):

function DoSomething(intParam1, strParam2) {
try {
if (isNaN(intParam1)) {
throw new Error(-1, "\"intParam1\" is not a number");
}
if ((typeof strParam2) != "string" || strParam2.length == 0) {
throw new Error(-2, "\"strParam2\" is an invalid or null
string");
}

return "example";
}
catch (err) {
throw new Error(err.number, "DoSomething() failed with
parameters intParam1=\"" + intParam1 + "\", strParam2=\"" + strParam2 +
"\". Message=\r\n" + err.description);
}
finally {
ClearUp();
}
}

function Main() {
try {
alert(DoSomething(1, "test"));
}
catch (err) {
alert("Oops, an error occurred:\r\n" + err.description);
}
}

Main();
--
Andrew Urquhart
- FAQ: http://jibbering.com/faq
- Archive: http://groups.google.com/groups?grou...ang.javascript
- Reply: http://www.andrewu.co.uk/about/conta...ject=Re%3A+clj

[Lee]

Eric Osman said:

Lee wrote:

Eric Osman said:

>It's too cumbersome to have to put a special check into function B to
>make sure that function C was able to make the required connection (not
>to mention function C having to communicate this to function B), plus
>having to then also put similar verification into function A etc etc.
That's how professionals generally write code. Function C should return
a status code (possibly just true or false) indicating success.

If we have to redesign function C to return a status code, then we have
to return the string elsewhere. Sure, there are ways to do this, like
return an object that contains both a status code and a string.

Not at all. On failure, you have it return a special string
that can't be confused with a valid return value, typically
an empty string.

Not sufficient. Routine C could be modified to return an empty string,
but then routine B needs to be taught to check for it, and then routine
B has to be redesigned (we didn't even discuss what routine B was
returning) and then all the calls to routine B have to be redesigned.

Yes. Welcome to professional programming. Note that there may be
some calls to B that don't need to check the status, and that, in
most cases, it should be better for a routine to return an empty
value than to simply fail. If you need to modify your B code to
handle the case of receiving an empty string, you might as well do
that now, rather than 3 months from now when you discover some
other case in which an empty string might be returned.
In other cases the situation could be even different. For example, ....This routine C doesn't return anything, and hence all the callers to it
don't check for any return value.
And so in that case, you return true or false, and modify the
callers that care to check the value. It's too bad that you
didn't realize the need for status checking earlier, but it
shouldn't be such a big deal to modify the calls.

Hmmm, is there a "throw" in javascript ? Maybe some condition can be
"thrown" to cause the stop ?

Throw was one of my suggestions in my original response,
but it's not supported in older browsers, and you'll still
want to modify the calling routines to catch the exception.