Re: break
On Apr 11, 11:13 pm, "a24...@googlemail.com" <a24...@googlemail.com>
wrote:
On Apr 10, 7:56 am, "Daniel Pitts" <googlegrou...@coloraura.com>
wrote:
On Apr 9, 10:21 pm, "Mike" <Sulfate...@gmail.com> wrote:
There are no situations where you MUST use recursion, however, there
are many circumstances in which is simplifies the implementation of
your algorithm.
And there are good reasons to avoid recursion in production code.
Unless you have complete control over the data it opens opportunities
for DoS attacks. Without additional guarding input data can eat up all
your memory, slows down your system and finally crash the
application.
Actually, threads have limited stack size, so you're more likely to
just get a StackOverflowError.
When you use an explicit stack you can easily put a limit to the stack
size and enforce it.
When you use the return stack you can control recursion depth by using
an additional recursion counter somewhere. But that is often
forgotten. Most algorithm textbooks don't demonstrate the problem, so
algorithms blindly copied from textbooks are a classic source of these
kind of bugs. And the code with a counter gets ugly. You either have
some external "global" variable and can forget about multithreading,
or you have to pass the counter down as argument.
In either case, you should always validate your input, regardless of
your implementation choice. If possible, you should validate your
input before you even get into the meat of the algorithm, so that the
program fails faster, rather than 30 minutes into a process getting an
exception.