Why doesn't JavaScript have a goto command?

[bgulian]

There is no logcal need for goto.

The lack of goto forces you to think of the correct way to solve your
problem, rather than relying on spaghetti code

Mostly true. Being fairly new to javascript, there may always be a
better way than goto. In C++ however, we often run into this (pseudo
javascript):

for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
goto globalError;
while (this_is_happening)
{
//something goes wrong
goto globalError;
}
}
//something goes wrong
goto globalError
}

globalError:
Something went wrong.


Now, you could use exceptions to achieve the same thing but exceptions
are painful in C++ as they may or may not get bubbled up to your
handler. Are they better in javascript? Barring exceptions though,
the abscence of goto means you must communicate the error to each level
of the nested loop. Worse than spaghetti code, in my opinion.

Bob Gulian

 

[Lasse Reichstein Nielsen]

Mostly true. Being fairly new to javascript, there may always be a
better way than goto. In C++ however, we often run into this (pseudo
javascript):

for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
goto globalError;
while (this_is_happening)
{
//something goes wrong
goto globalError;
}
}
//something goes wrong
goto globalError
}

globalError:
Something went wrong.

The better way in this case is a labeled break:

outerloop:
for (i=0; i < limit; i++) {
for (j=0;j < jlimit; j++) {
//something goes wrong
break outerloop;
while (this_is_happening)
{
//something goes wrong
break outerloop;
}
}
//something goes wrong
break outerloop;
}


It uses nothing but the break feature, the general idiom for breaking
out of a loop early. The label is only there to allow you to identify
the loop to break out of if it is not the closes enclosing one, the
break is the same.

Now, you could use exceptions to achieve the same thing but exceptions
are painful in C++ as they may or may not get bubbled up to your
handler.

Don't know exceptions in C++.

Are they better in javascript?

They are fairly simplistic in Javascript. There are no exceptions
classes/types, so you can throw any value, and a catch catches
all exceptions.

Barring exceptions though, the abscence of goto means you must
communicate the error to each level of the nested loop. Worse than
spaghetti code, in my opinion.

I'm not sure where labeled break was first introduced. It existed in
Ada, and is in most recent languages like Java, Javascript and C#.
It's conceptually much nicer than the otherwise equivalent "goto
label just after loop"

/L

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Wed, 8 Mar 2006 07:56:00 remote, seen in

Being fairly new to javascript, there may always be a
better way than goto. In C++ however, we often run into this (pseudo
javascript):

for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
goto globalError;
while (this_is_happening)
{
//something goes wrong
goto globalError;
}
}
//something goes wrong
goto globalError
}

globalError:
Something went wrong.


Now, you could use exceptions to achieve the same thing but exceptions
are painful in C++ as they may or may not get bubbled up to your
handler. Are they better in javascript? Barring exceptions though,
the abscence of goto means you must communicate the error to each level
of the nested loop. Worse than spaghetti code, in my opinion.

No "must" about it; put both loops in a function, return false for error
and true for success, and test that return result. You could, I expect,
upgrade your C that way too.

Perhaps there is or should be a Web page on obvious constructs and
appropriate codings.

 

[Richard Cornford]

I work for myself.

You programming colleagues will be pleased to hear that

If I had to hire elite JavaScript programmers
that insist on not using goto I would be out of business.

Last week you were claming your business to be so successful that you
didn't need to worry about supporting more than default configurations
of one browser, this week it is so marginal that you cannot afford to
employ people who have the skill you perceive as necessary (i.e. the
ability to write javascript).

Yet several of my JavaScript programs are practical and
solve very complicated linear programming models in the
electrical field where I am an expert.

I assume that is "solve" in the sense of 'behave as expected when
minimally tested with acceptable inputs', given how easily RobG found
bugs with non-expected input.

One thing that is certain is that your programs will die with you,
because anyone seeing your spaghetti code is likely to prefer to
re-write from scratch rather than commit themselves to the burden of
attempting ongoing maintenance (unless you can find someone particularly
masochistic, or who doesn't know any better themselves).

I want a goto statement, because it would make my programming
life easier.

Only in he sense that it would allow you to carry on 'programming'
without learning to do without goto. But learning to program without
goto is what would actually make your programming life easier. And I say
that as someone who first learnt programming in the days when BASIC had
a number for every line and goto was virtually the only way of jumping
about in a program. I stopped using goto in BASIC with the first version
that had subroutines and found the results considerably easier to code
and maintain.

I quite liked the mental challenge of trying to maintain a consistent
mental model of code written in early BASIC. The more complex the code
gets the bigger the challenge, but the unfortunate reality is that the
human capacity to comprehend complexity is limited and once you go
beyond 2,000 - 4,000 statements the ability to perceive the whole system
in code terms is exceeded, and spaghetti code just degenerates into an
unmanageable mess, getting more chaotic with every addition.

It is dealing with the limited human ability to comprehend complexity
that has forced programming languages to evolve, and they have evolved
in a way reduces large interdependent programs into autonomous units
that are simple enough to comprehend (and vigorously test) in isolation,
and shifts the challenge of comprehending the system up a level (or two)
to the interactions between those now abstracted units.

The intellectual challenge of comprehending 2000 lines of spaghetti
BASIC filled with goto statements transforms into the challenge of
comprehending the architectural and design aspects of the
interrelationships between a few hundreds of objects implemented with
60,000 lines of code. And is, in the end, a more rewarding application
of the intellect and orders of magnitude more productive.

The strategies that make the big, complex, systems manageable make the
smaller programs, that can be implemented in 2000 odd lines of code,
relatively simple. And that is what makes your programming life easier
in the long run.

I like to spend my time on subject issues, not programming
issues.

You are unlikely to appreciate how much time you have wasted on
modifying/maintaining spaghetti code until you have learnt to write
non-spaghetti code (as you will not get to work on code written by
others while you work for yourself and will not employ real
programmers), so you are not really in a position to judge what
proportion of their time is spent on "subject issues" rather than
programming issues by professional programmers.

I used the older languges quite efficiently before JavaScript
came along,

Where is your benchmark for "quite efficiently"? You have not been
working alongside other programmers so how do you know that what your
perceive as efficient is not horribly inefficient by comparison?

and I often used goto.
I really do think I will be looking at Visual Basic Script.
If it has a goto I may just goto vbscript and give MS even
further credit for out doing Sun.

If that is what you want to do, do so. It would be solving the wrong
problem but if you insist upon fixating on an imagined need to use goto
you won't make any more progress with javascript.

No way!

No way? Are you saying that it is impossible to program without goto?
That would mean that all of that code written in Java, javascript and a
host of other recent languages (not to mention older languages that
retain goto but where it would never be used by competent programmers)
doesn't actually work. I think someone would have noticed that by now
and said something.

Fortran still has goto and has for longer than most
JavaScript programmers have been alive.

The vast majority of javascript programmers are older than the language
is, many will be younger than Fortran. But a programming language being
old is not in itself a good thing, lessons have been learnt from what
has gone before, and one of the drawbacks of the older languages that
have been updated is that they tend to retain features for no reason
other than backwards compatibility, while new languages get to ditch the
dross entirely.

And I suppose Perl is not a Modern Language?

No not really, but I said "new languages" anyway.

Perl has a goto.

C++ has goto as well, though you wouldn't expect to see it being used
often, if at all.

Furthermore, I really wonder how many of the "modern"
JavaScript programmers know iota about Fortran IV.

I very much doubt that any 'modern' javascript programmers know how to
set the switches and wire the plugs on an ENIAC, but I don't anticipate
any of them suffering for the lack of that 'skill'.

Richard.

 

[Randy Webb]

Dr John Stockton said the following on 3/8/2006 5:04 PM:

Perhaps there is or should be a Web page on obvious constructs and
appropriate codings.

There are. Below are at least two of them.

 

[sam.partington]

for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
goto globalError;
while (this_is_happening)
{
//something goes wrong
goto globalError;
}
}
//something goes wrong
goto globalError
}

globalError:
Something went wrong.


Now, you could use exceptions to achieve the same thing but exceptions
are painful in C++ as they may or may not get bubbled up to your
handler. Are they better in javascript? Barring exceptions though,
the abscence of goto means you must communicate the error to each level
of the nested loop. Worse than spaghetti code, in my opinion.

(snip)

No! Absolutely no! This is absolutely the wrong way to do this in C++
or javascript.

Exceptions are not painful in C++, there is no "may or may not" get
bubbled. They WILL propagate. The above code is even less appropiate
in C++ than it is in javascript.

I can think of several ways to solve the above problem :

1. Use exceptions - this is the best way.

2. Break down the complex three level loops into smaller well defined
functions, or use algorithms.

3. If you absolutely can't use exceptions add an error condition into
the loop condition expression -- its not that hard, and its a lot
clearer in intent *.

4. If you are using error codes you can even return a failure error
code in the inner loop. In javascript any resources will be cleaned up
by garbage collection, in C++ your destructors will handle it.

Seriously, if you're writing C++ code like this you need to read up on
some modern C++ style. Try effective C++ by Scott Mayers for starters.

Sam

 

[bgulian]

No! Absolutely no! This is absolutely the wrong way to do this in C++
or javascript...

Thanks to LRN for furthuring a constructive discussion with real code
and an elegant way to solve the problem I stated. Thanks to the rest
of you for the grandstanding, ego polishing, and the usual entertaining
stuff that once in a while imparts some great knowledge. You actually
made me have some sympathy for the spaghetti coding electician.

Seriously, if you're writing C++ code like this you need to read up on
some modern C++ style.

I exampled a code construct that have encountered many times in my code
and other people's code. I am trying to find a way that is better. LRN
gave me one.

Bob Gulian

 

[sam.partington]

I exampled a code construct that have encountered many times in my code
and other people's code. I am trying to find a way that is better. LRN
gave me one.

Look sorry, I didn't want to start a flame war, the thing that annoyed
me was the comment about C++ exceptions being buggy, which is simply
not true, and you made no effort to back up the statement with a
reference or examples.

This has all been covered before, for every new language that comes
along, PHP for example :

http://www.procata.com/blog/archives/2004/07/29/goto-in-php/

In fact is has become satirical in its use :

http://www.entrian.com/goto/

Its not just an academical holier-than-thou thing, its a prejudice that
has been built up by developers in lots of languages after years of
experience of debugging and maitaining complicated code.

I did offer 4 alternatives to your posted code, here are two of them
spelt out of course they are a bit artificial. The benefits of the
exceptions method being :

- You can't ignore the error.
- You don't need to litter all your functions with return codes.
- Errors can propagate from the lowest level small helper functions
right up to the caller who can do something useful with the error.
- The caller can decide at what level to handle the error.
- The larger the app, the more beneficial using exceptions becomes.

1.
try
{
for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
throw err_code_1;
while (this_is_happening)
{
//something goes wrong
throw err_code_2;
}
}
//something goes wrong
throw err_code_3;
}
}
catch (err)
{
document.write("An Error Occurred: " + err);
}

(or better yet, let the error propagate to the caller, who can
probably do something more useful)


2.
function do_it()
{
for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
return err_code_1;
while (this_is_happening)
{
//something goes wrong
return err_code_2;
}
}
//something goes wrong
return err_code_3;
}
return 0;
}

var err = do_it();
if (err)
{
// whatever
}

 

[Tim Streater]

Look sorry, I didn't want to start a flame war, the thing that annoyed
me was the comment about C++ exceptions being buggy, which is simply
not true, and you made no effort to back up the statement with a
reference or examples.

This has all been covered before, for every new language that comes
along, PHP for example :

http://www.procata.com/blog/archives/2004/07/29/goto-in-php/

In fact is has become satirical in its use :

http://www.entrian.com/goto/

Its not just an academical holier-than-thou thing, its a prejudice that
has been built up by developers in lots of languages after years of
experience of debugging and maitaining complicated code.

[...]

Of course its also true that I can write FORTRAN in any language. By
which I mean that any language can be abused and have spaghetti written
in it, goto or not.

I suspect Mr Electrician would complain more about Pascal even though it
has goto, than other languages. The fact it didn't have a return
statement made me abandon it very quickly. In the end I just put a dummy
statement with label 999 at the end of every procedure and goto'ed there
when I needed to return.

-- tim

 

[bgulian]

(e-mail address removed) wrote: ..

1.
try
{
for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
throw err_code_1;
while (this_is_happening)
{
//something goes wrong
throw err_code_2;
}
}
//something goes wrong
throw err_code_3;
}
}
catch (err)
{
document.write("An Error Occurred: " + err);
}

Yes, you're right. The above is actually the best way to do it. I
have been wary of exceptions because, at least at one time, lower
levels of exception handling (like in 3rd party libraries) did not
bubble up to my code if the library caught the exception and did not
propagate (throw) it. It made using them a guessing game so even
though they were useful at a local level, it didn't seem worth it for
commecial apps that use a lot of 3rd party apps. Not to mention that on
Windows there has been, until recently, two models of exception
handling to furthur confuse developers.

(or better yet, let the error propagate to the caller, who can
probably do something more useful)


2.
function do_it()
{
for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
return err_code_1;
while (this_is_happening)
{
//something goes wrong
return err_code_2;
}
}
//something goes wrong
return err_code_3;
}
return 0;
}

var err = do_it();
if (err)
{
// whatever
}

Well, this is a design issue. Would there even be a relevant error
code if some minute mathematical calculation of an inner loop went
astray? And even if there were, what if you wanted the error message
to use values of all the variables in do_it()? You'd have to pass them
back too, as a collection object or something.

In any case, thanks for replying. For the case I presented, using a
javascript exception is the best route.


Bob Gulian

 

[Richard]

GOTO was replaced by methods, functions, and classes when programming
languages saw that it was more efficent to build libraries that could be
imported into any project. OOP, Object Oriented Programming, takes using
redunant code and simplifies it by creating an object. This object can
then be called anytime throughout the program the same was as you would
use a GOTO statement. Unlike a GOTO statement the code can that is being
called can reside in outside of the program calling it. When I used GOTO
statements in Basic if I found a function I liked I had to copy and
paste it to another program to be usefull. Also, objects are loaded into
memory once and called when needed and then the garbage collector cleans
the memory when it is no longer needed. A GOTO statement will load into
memory each time it is called making it ineffienct for larger programs
that require large amounts of memory to produce results.

An example of an object would be like creating an apple. You have the
framework for it; red skin, the shape, core, etc.. You use one object to
create a whole bushel even thought they are located on different spots
on the screen they still only access one part of the memory.

 

[sam.partington]

Yes, you're right. The above is actually the best way to do it. I
have been wary of exceptions because, at least at one time, lower
levels of exception handling (like in 3rd party libraries) did not
bubble up to my code if the library caught the exception and did not
propagate (throw) it. It made using them a guessing game so even
though they were useful at a local level, it didn't seem worth it for
commecial apps that use a lot of 3rd party apps. Not to mention that on
Windows there has been, until recently, two models of exception
handling to furthur confuse developers.

We've only recently started to discover the true benefits of
exceptions. Until recently we used them only as local library specific
exceptions. And our older projects still do. It can be a pain
translating exception types from one library to another, or from
exception to error codes, or vice versa.

In your case, if the third party library did silently catch the
exception, and not notify the caller at all then it seems to be a
design error on the libraries part. Not that assigning blame helps
when you're trying to solve the issue!

But with more recent projects we've used them as part of an application
wide error handling strategy, and it has made our code (which is used
on an embedded device) considerably simpler, with a fraction of the
number of if() {} else {} ... constructs.

But of course exceptions are no panacea and yes it can be a pain when
third party libs throw different types and you need to translate
between them.

Well, this is a design issue. Would there even be a relevant error
code if some minute mathematical calculation of an inner loop went
astray? And even if there were, what if you wanted the error message
to use values of all the variables in do_it()? You'd have to pass them
back too, as a collection object or something.

Tricky one yes. In C++ I'd handle the first one as a derived class of a
more generic mathematical exception class. If the caller cared what
type of exception occurred it could catch that specifically, or if it
didn't care catch the general mathematical case.

I don't know how I'd map that to a javascript design. I guess you could
add sub error code properties to the exception type. Something like

function Error(code)
{
this.code = code;
}

function ErrorWithSubCode(code, subcode)
{
this.code = code;
this.subcode = subcode;
}

For the second problem yes I suppose you'd have to throw a collection
at the end of the loop, which is a bit messy. But then you don't need
the goto anyway because you want the loop to continue until you've
tried all combinations, and completed your list of errors. I'd still
probably use an exception for the inner most loop though, with the guts
of the code taken out into a different function.

In any case, thanks for replying. For the case I presented, using a
javascript exception is the best route.

I'm glad we are agreed with each other. Sorry for being on my high
horse.

sam