The first thing you do is unravel all that crap to a normal loop so you can debug it properly.
And when you're done, you really don't want to go back to the stream way of doing just in case it breaks again and you need to start debugging once more.
>> ...stream().
map(e -> e.getKey().getPrice().multiply(new BigDecimal(e.getValue()))).
reduce(BigDecimal.ZERO, BigDecimal::add)
The trick with java and chaining calls is that you have to do the chain on each line, so the stack track can pinpoint the line it failed at.
so instead of the above, write the code as:
...stream().
map(e -> e.getKey()
.getPrice()
.multiply(new BigDecimal(e.getValue())))
.reduce(BigDecimal.ZERO, BigDecimal::add)
But less flippantly, what other tool is workable for Java?
I can see a company deciding to do that for internal projects. But if it's open source, I'm certainly not interested in creating a situation where it's difficult to comply with a project's coding standards without buying a $500 piece of software.
...this, to me, speaks to a huge tooling failure. The stack trace should have precise information about the region of the source file that the call was embedded in (line+column start+end), as opposed to merely the line.
Where it goes wrong IMO is where a mix of styles and too many inline lambdas splatter a mess of logic into some god-method.
As other comments note, good formatting will help with intelligibility of failures - and IMO sensible logging (at least of error paths) makes it all rather noce to debug.
That’s not the point they were making. The point is that when you start chaining together so many calls, it can become difficult to debug. Prettier to write, but more difficult to debug. But that’s okay, you need to find the balance that’s appropriate for the particular project.
If getPrice fails, the stack trace will start there. If it returns null (which it should not) and trigger a npe, then the line:
map(e -> e.getKey().getPrice().multiply(new BigDecimal(e.getValue()))).
sum = sum.add(entry.getKey().getPrice().multiply(new BigInteger(entry.getValue())
Second.
The key thing with streams is to borrow from the functional programming paradigm: Split data and functions, avoid or isolate side-effects.
Do this correctly and there is a quite real plus in productivity.
There as a bit of zen to it, less is more, in sense that a language gets more powerful if it is more constrained. For example if you know (by the type system or just coding conventions) that p.getPrice() nevers returns null, it is easier to reason about (proof, test, read) the code.
Like wise if you know that if p1 == p2 then p1.getPrice() == p2.getPrice() (that would be no side effects).
If you as some one suggested, need to support some crazy localization, then don't put it into p.getPrice(). If you must, change the name to something telling and make its input explicit: p.calculateLocalizedPrice(locale). Or better make it an explicit function (static method, or maybe something sitting in a service) calculateLocalizedPrice(product, locale) and again have it be without side effects.
Having no side effects is a different very useful quality - function doing exactly as specified and no more (I/O, setting variables ..). I'm not sure if it means not accessing global state, though it is usually better if both inputs and outputs are explicit.
All in, it is usually easier to reason about functions that are explicit, deterministic and side-effect free, yet I find it profoundly more valuable if it can actually be relied on (a known subset of) functions having those qualities.
[1] https://maksimivanov.com/posts/pure-functions-and-side-effec...
Imagine you have two methods in Java:
int add(int a, int b) {
log.info("Adding two numbers {} {}", a, b);
return a + b;
}
void doStuff() {
add(1, 2);
add(2, 3);
add(3, 4);
}
In languages that understand "pure functions" there are optimizations that can be done by the toolchain (think automatic memoization, deferred computation, and much more) when only pure functions are called.
I've found the stream debugger in IntelliJ to be very useful when looking at debugging streams.
https://www.jetbrains.com/help/idea/analyze-java-stream-oper...
The old plugin version of it has the same functionality (and better pictures) - https://plugins.jetbrains.com/plugin/9696-java-stream-debugg... (click the 'more' link)
Selecting a piece of data within the stream shows you how it moved through the stream.
The other part of streams, for me, is that with the additional "each line does one, and only one thing" and you're not putting too much complexity in a single map, I feel that it forces you to write simpler code that doesn't need much debugging. The question of "how did that data get into the stream is where most of the debugging comes from.
Maybe getPrice used to be a static lookup from a map that couldn't fail, but then the Sales Team wanted to go multi-national and now it's a database lookup with multiple dependencies, that can fail.
"But why wasn't it caught in a code review" etc...
Have you actually worked with a big team ever? Why would (or how could) anyone (outside of Google) go through every dependency of the getPrice function and check that every use case is handling errors/exceptions properly?
Stuff breaks, code is read and debugged more often than it's written. Optimising stuff to be easy and fast to write is the wrong way to make maintainable code. Unroll your loops, add toggleable debug logging and add comments why stuff is done the way it is.
This is exactly why people like collection functions. For loops can do anything, you have to spend more time reading and understanding the loop to build your mental model of what is happening. Mapping does one thing, transforms a collection into another collection. Same with filter, etc. If you are optimizing for readability, collection functions give way more information to the reader. Your approach is to optimize for debugging, which I'm not saying is wrong, but it's not optimizing for readability.
It is chaining that obfuscates in this case. Through, I really don't find functional style more readable in general.
getPrice might start up as something that just gets the price, after 5-10 years it might be a complex process accessing some ERP systems.