Forum Discussion
Lambda Example: Generate Fibonacci series
In this case error handling could be carried out by wrapping in another function as suggested by Viz , the n = INT(n) condition is not iterated then. In general there will be the performance/error propagation considerations you mention so better to avoid adding extra conditions inside recursive functions if possible.
That's the question better to avoid or better not to avoid. I guess LAMBDA(), as well as simple LET(), don't improve the performance themselves compare to set of formulas and named cells/ranges, suspect they decrease it. What they improve that's flexibility and maintainability. From this point of view perhaps better not to avoid if only performance not becomes a critical issue for the concrete project. Again, I don't care about Fibonacci case, that's only an example.
I suspect you are right that while LAMBDA / LET solutions may add flexibility and maintainability they may often be a little less efficient than more traditional solutions involving helper ranges.
For discussion it's helpful to have some concrete examples in mind. Many common problem scenarios involving manipulating data tables in various ways could be implemented using DA methods without the need for recursion in which case inserting extra conditions is not much of an issue particularly if these conditions can be hidden from view inside LAMBDA so as not to be a source of distraction.
One broad class of problem where recursion would generally be required are formula solvers. For financial models obvious examples include yield-to-maturity, implied volatility and bootstrapping (curve fitting) calculations. Here the objective is to find a solution to a model which is satisfied within a given bound. IMHO an idealistic approach for these type of cases would keep the recursive code compact so it can be easily translated into business logic and use wrapper functions for implementing any additional conditions as suggested above.