1.
[syn: fall through, fall flat, founder, flop]
WordNet (r) 3.0 (2006):
fall through
v 1: fail utterly; collapse; "The project foundered" [syn: fall
through, fall flat, founder, flop]
Moby Thesaurus II by Grady Ward, 1.0:
19 Moby Thesaurus words for "fall through":
break down, collapse, come to naught, come to nothing, crash, fall,
fall dead, fall down, fall flat, fall in, fall short,
fall stillborn, fizzle out, get bogged down, get hung up,
get mired, go to smash, peter out, poop out
The Jargon File (version 4.4.7, 29 Dec 2003):
fall through
v.
(n. fallthrough, var.: fall-through)
1. To exit a loop by exhaustion, i.e., by having fulfilled its exit
condition rather than via a break or exception condition that exits from
the middle of it. This usage appears to be really old, dating from the
1940s and 1950s.
2. To fail a test that would have passed control to a subroutine or some
other distant portion of code.
3. In C, ?fall-through? occurs when the flow of execution in a switch
statement reaches a case label other than by jumping there from the switch
header, passing a point where one would normally expect to find a break. A
trivial example:
switch (color)
case GREEN:
do_green();
break;
case PINK:
do_pink();
/* FALL THROUGH */
case RED:
do_red();
break;
default:
do_blue();
break;
The variant spelling /* FALL THRU */ is also common.
The effect of the above code is to do_green() when color is GREEN, do_red()
when color is RED, do_blue() on any other color other than PINK, and (and
this is the important part) do_pink() and then do_red() when color is PINK.
Fall-through is considered harmful by some, though there are contexts
(such as the coding of state machines) in which it is natural; it is
generally considered good practice to include a comment highlighting the
fall-through where one would normally expect a break. See also Duff's
device.
The Free On-line Dictionary of Computing (30 December 2018):
fall through
fall thru
(The American misspelling "fall thru" is
also common)
1. To exit a loop by exhaustion, i.e. by having fulfilled its
exit condition rather than via a break or exception condition
that exits from the middle of it. This usage appears to be
*really* old, dating from the 1940s and 1950s.
2. To fail a test that would have passed control to a
subroutine or some other distant portion of code.
3. In C, "fall-through" occurs when the flow of execution in a
switch statement reaches a "case" label other than by
jumping there from the switch header, passing a point where
one would normally expect to find a "break". A trivial
example:
switch (colour)
case GREEN:
do_green();
break;
case PINK:
do_pink();
/* FALL THROUGH */
case RED:
do_red();
break;
default:
do_blue();
break;
The effect of the above code is to "do_green()" when colour is
"GREEN", "do_red()" when colour is "RED", "do_blue()" on any
other colour other than "PINK", and (and this is the important
part) "do_pink()" __and then__ "do_red()" when colour is "PINK".
Fall-through is considered harmful by some, though there are
contexts (such as the coding of state machines) in which it is
natural; it is generally considered good practice to include a
comment highlighting the fall-through where one would normally
expect a break. See also Duff's Device.