So before build a convoluted function or series of variables, is there a way to jump out (multiple steps) of a nested "if" loop in Javascript? In C you can use a goto and I see continue works in "for" loops (even nested ones) but I don't see anything that helps here (I have read and am currently searching through Flanagan's book for an answer).
if (x){
//Do some other things then...
if (y){
//Do some other things then...
if (z){
goto SkipMsg;
}
//Do some other things
}//Do some other things
SkipMsg:;
}
Break would only get me out of one of the "if" stetements.

You might be better off with a switch statement which is the classic way of doing a one of many selection. If is classic for a one of two selection and becomes cumbersome if you want to build a selection tree

You know, you can also use try/catch and throw exceptions (an exception does not have to be an error.)

You might want to google for this topic as things such as eval() are not clearly discussed in Flanagan but you can finds lots of information on the web.

I believe javascript supports the goto statement and line markers such as

doThis:
doThat:

It could be wise to put a selection tree in a separate function, not only just to make your code more readable, but to make use of the nice feature of the explicit return statement, with which you escape from the selection tree whenever you want ! Furthermore, it offers the great possibility to pass values to the calling function. In that separate function you can of course use switch and try too, next to or in place of nested if's.

function xyz() { // the calling function
var result;
statements setting arguments
result=selectionTree (arguments you need to decide upon);
switch (result)
case "expr 2 true":
et cetera

function selectionTree (arguments you need to decide upon) {
if (expr 1) {
do this and that
if (expr 2) {
do these things also
return "expr 2 true"}
else {
do other things
return "expr 2 false"}
if (expr 3) {
return "expr 3 true"}}}

Just a note on goto.
I don't want to be patronizing, and with all due respect to Lyndel, who merely just said it is possible, but probably never uses goto's himself ;-), that would surprise me.

Avoid goto's completely, even if they are provided by a language (unless that language does not offer other solutions of course, but that is very unlikely as far as I know). Goto's are an old technique coming forth from procedural languages. There has been a huge struggle in the 70ties and 80ties to learn people how to avoid them with a technique called gotoless programming. Goto's often lead to pretty unreadable code and mistakes. Goto's (or better the misuse of) were one of the triggers that lead to better features in languages. Goto and their labels also disrupt your otherwise nicely built functional structure.

Back in the 60's when gotos were used, I forced a machine designer to build into the processor a register called "came from". The processor saved the instruction counter in that register whenever a jump (Goto) took place. I don't think I was the originator, I am sure other machines (they were very proprietary at the time) had a similar feature. My crusade back then was that a processor should support features of programming languages not the other way around which was the IBM methodology. The worst example being the IBM 7094 and the language modeled after its instruction set called "Fortran"

Fortran4 was a fun little language -- except for those crazy three way IF (,,) statements. I never enjoyed them. I drove my instructors crazy because I used mostly used computed GOTO's. All of the other students' programs were the standard mess of IF's and simple GOTO's. My programs were much more streamlined and easier to deal with. Some time later I found out that this technique has been given a name -- "State Machine".

Rather than forcing a favorite (or only) language to conform to the task, I think that the programming language should be picked to match the job at hand.

APL is still my favorite language. I once wrote a graphics package in APL that supported a vector graphics terminal. One could edit and preview the plots on screen, then generate a punched card deck that eventually drove a flatbed plotter. The whole program was a few pages of code. One of the novelties was that there were no loops in the program -- in APL this sort of task is simple fall through code.

There was one branch (goto) in the package. I briefly struggled with that section, but the whole function was so short and straight forward that a branch elimination technique would have obfuscated the whole routine. In that case the only reason not to use a branch was for bragging rights -- "look mom, no goto's".

You're right about the mess simple goto's caused. Computed goto's and APL have been my favorites too, but that is a long time ago. Computed goto's because there were little alternatives. APL because you could program nice functional blocks, small entities of instructions dealing with one functional purpose, and a huge collection of statements. Even inner and outer join. A glimpse of future languages. Still in many things a language superior to many other, like dealing with matrices.

The switch statement looks like a computed goto, from which it was probably derived. Unfortunately it allows fall through, unless you break the flow in each case, which is the only right way to deal with switch. Errors in fall through are very difficult to detect. Likewise simple goto's look attractive, but can cause errors that are also very difficult to detect if one doesn't use them properly.

To my surprise, I learned that it was much easier to learn people how to deal properly with functions than how to deal properly with those simple looking goto's. A nice side effect was that my maintenance budget dropped drastically: programs became easier to understand by those that did not write them. Although indeed in a few cases goto's were a good solution, mostly written by or under supervision of (method)knowledgeable programmers. We did not go completely gotoless. It is from that experience that I write "avoid goto"s.

Having said that, I do think in Javascript you don't need them anymore (IMHO), with the advantage that you don't fall into the goto trap: becoming blind for better solutions.

Quoting Crockford: the worst features of a language aren't the features that are obviously dangerous or useless. Those are easily avoided. The worst features are the attractive nuisances, the features that are both useful and dangerous.

JavaScript (iirc) does allow you to break out of specific (named) code blocks though. Something I avoid (though possibly only because it's new-fangled ;)

Chris.

Fortran 4, I was talking Fortran I. The three way if was in the language because the IBM 7094 had a single instruction that did a three way test and branch. It executed the next instriction if the predicate was<0, skipped one instriction if the predicate=0, and skipped two instructions if the predicate was>0.

Yes APL was also one of my favorites but I always knew it as Iverson Notation (Ken Iverson of IBM was the originator). Iverson notation, which was popularized as APL, was designed to be able to emulate a machine for software testing before the machine was built. In fact IBM published in one of the issues of the IBM System Journal a complete emulation of system 360 written in Iverson Notation.

APL programs were unique in that the commentary to explain the program was generally much longer than the program.

An APL a day keeps the doctor away! It was fun to riminisce about the goodies. I'm sorry to have disrupted the thread by adding a goto note.

Going back to the original question how to escape from nested if's. What have we learned here?

You can escape from nested if by using:

- switch (with break & default) instead of complex if
- try 'n catch
- throw
- explicit returns in a separate decision function
- labeled breaks

In what specific cases are labeled breaks worth a recommendation above other escape methods?
Any comments on using explicit returns?

I just don't use an if for greater then a 2 way choice if I can help it. I find that switch/case with Return/Break cover all my needs. The fact that the switch (unlike a select in basic) will perform all cases where the predicate matches is handy since you can always put in a break or return to stop the case train.