Debugging lambda expressions

[Roel De Nijs]

Until now I didn't get my hands dirty on lambda expressions (shame on me, I know ), so this might be a stupid question.

So far I have seen plenty of lambda expressions and I always wonder how you can debug this kind of code. Because these statements mostly are "one line" statements (using method chaining) and you'll probably be interested in the predicate itself and not in the implementation code of e.g. the filter method.

Reusing the same problem (print all the odd numbers in a list greater than 15 without any duplicates) from my other thread. Let's assume there's a bug in our code (just hypothetical of course, we don't write bugs ). How can you debug your code?

With the non-functional solution of your code it's fairly easy: you set a breakpoint on the line with the if statement and with each iteration you'll be able to inspect variable i and see if it's added to set or not:

Set<Integer> set = new HashSet<>();
for (Integer integer : list) {
  int i = integer.intValue();
  if (i > 15 && i % 2 == 1) {
    set.add(integer);
  }
}
System.out.println(set);

But with the Java 8 code, it seems less straightforward.

list.stream()
  .filter(i -> i % 2 == 1)
  .filter(i -> i > 15)
  .collect(Collectors.toSet())
  .forEach(System.out::println);

If I put a breakpoint at the 1st filter statement will it stop with every iteration without going through the filter method itself. Or do I need to format my code in a specific way to achieve this goal, e.g.:

.filter(
  i -> i % 2 == 1
)

Probably depends on the IDE you will be using...

Kind regards,
Roel

[Jeanne Boyarsky]

In Eclipse, setting a breakpoint works fine with the original formatting. First, Eclipse stops in the i%2 part. If I keep pressing F7 (step into), it eventually gets into filter method. Granted this isn't terribly useful, but I think it is what you asked about.

I use three main techniques for working with lambdas:
1) Unit tests (regression is nice)
2) The peek method so I can see what is in the stream at different points in time.
3) A conditional breakpoint so I can stop on a certain pass.

List<Integer> list = Arrays.asList(14,15,16,17,17,18,19);
list.stream()
  .filter(i -> i % 2 == 1)
  .peek(i -> System.out.println("Debug: " + i))
  .filter(i -> i > 15)
  .collect(Collectors.toSet())
  .forEach(System.out::println);

[Roel De Nijs]

Jeanne Boyarsky wrote:In Eclipse, setting a breakpoint works fine with the original formatting. First, Eclipse stops in the i%2 part. If I keep pressing F7 (step into), it eventually gets into filter method. Granted this isn't terribly useful, but I think it is what you asked about.

As an Eclipse user myself, that's exactly what I wanted to know Maybe IDEs will improve in the future to debug lambda expressions more easily.

Jeanne Boyarsky wrote:I use three main techniques for working with lambdas:
1) Unit tests (regression is nice)
2) The peek method so I can see what is in the stream at different points in time.
3) A conditional breakpoint so I can stop on a certain pass.

Seem to be very reasonable techniques. Certainly number 1 (of course) and 3, the 2nd one reminds me to the dark age of webapp development when you had to use nothing but alert statements to debug your javascript code. Those good old days!

[Cay Horstmann]

I'd like to add a thought to the very nice explanation how to use the Eclipse debugger. Have another look at the loop and the Java 8 code. With the loop, it's very reasonable to ask "How do I debug that?"

But with the stream code? I mean, we filter to keep even numbers, and numbers > 15, then put them in a set, and print them.

What is there to debug???

That aspect of lambdas sometimes gets overlooked. Together with a well-designed library, they can reduce your debugging effort because the code just does what it should.

Cheers,

Cay

[Roel De Nijs]

Cay Horstmann wrote:But with the stream code? I mean, we filter to keep even numbers, and numbers > 15, then put them in a set, and print them.

What is there to debug???

That aspect of lambdas sometimes gets overlooked. Together with a well-designed library, they can reduce your debugging effort because the code just does what it should.

That's of course true! With lambdas you only have to focus on what needs to be done and let the API take care about the rest.

In this very simple example you'll see with just a glance what's happening and what the code will do. But I have seen much more complicated examples (20-25 lines), certainly if you need to write your own custom downstream collector with a supplier, accumulator, and combiner. Then it could be useful to have the possibility of debugging your code.