This has been a spectacularly intensive week. The new carrying the course is exploding with subscriptions; it's just entering its 3rd week... YouTube channel The is now live; you can see the entire course there although I'm adding videos all the time and did roughly 1/3 of the work. course website Right now, it has 3 hours and 17 minutes of content. I have another hour of content ready to add, and I'm working on several more. I'm pretty sure the course will be well over 6 hours when completed. I'm also working on some other interesting videos such as one about . I'll write a full blog post covering it in the coming weeks. protecting yourselves from serialization exploits If you have any questions, thoughts, or ideas, I'd love to hear from you. Below is this week's video and the transcript. https://www.youtube.com/watch?v=DGjVVKCNosM?embedable=true Transcript Welcome back to the third part of debugging at Scale where we learn to hunt bugs like the pros! In this section, we’ll discuss watch expressions which are the cornerstone of debugging. This is so important I’ll revisit the subject again later on. The watch area is the area at the bottom of the screen In IntelliJ, we can also embed watch expressions next to the code. The watch is one of the most important capabilities of a debugger. This is how we can see what’s going on in the debugger. But I’ll go much deeper than that. Especially for object marking which is one of the coolest debugger features ever. Return Value Have you ever returned from a method only to think, “what did that method return?” This is very common especially when the return value isn’t stored in a variable. Luckily, the IDE has the option to save that value for us so we can inspect it right away! By enabling this option, we can see the return values from all future methods. If we step into the method and then step out, you will be able to see the return value for the method at the bottom here. isPrime Evaluate Evaluate expression is one of the cool features of the debugger that we don’t use enough. We can launch the evaluate expression dialog from the right-click menu and type in any valid Java expression. This is a powerful tool that can invoke any method, do arithmetic, and even change the value of variables as a result. If you need to simulate something that’s hard to test in the current code, this is the place where you can play with the platform and test out “wild theories”. This is very much like the REPL we have in newer versions of Java, but it’s better in many ways because we can execute code in the context of our application. If I have a method that returns the wrong value, I often copy the call into an evaluate dialog and try various combinations of the call to see “what works”. Just trying all the options without restarting can save us a lot of time! You can launch this dialog with the key combination. Alt-F8 Watch The watch ability in IntelliJ is absolutely spectacular. IntelliJ lets us embed the watch directly into the IDE editor by selecting “Add Inline Watch” from the context menu. This is an amazing feature that, as far as I know, is unique to JetBrains. Once selected, the watch appears on the right next to the line where we added the inline watch which makes it easy to evaluate with the code. This is very convenient when returning to the same line over and over again. We can also use the standard watch which will add elements with the other variables. This is useful for objects we want to track over large areas of the code. I have a lot to say about the watch area as we move forward but for now, let’s put this on hold. Change State Set value is a feature I often forget to use when debugging. That’s a shame because it’s so powerful. We can set the value of any field by right-clicking it and selecting set value. We can also use to speed this up F2 I can change the value to any arbitrary value. This can also apply to objects where I can assign an existing value or invoke a creation method, a new statement, or any expression I want. It’s a remarkably powerful feature where we can mutate the object dynamically to reproduce a state we want to test. We can combine this capability with jump to line that we discussed previously and test a method through many different permutations. Even ones that might not be reproducible normally. A good example would be code that I have that only runs on Windows. But I have a Mac. I just change the value of the static variable that indicates the current operating system and test that code. Object Marking Object marking is one of the coolest features we’ll discuss in this course and it’s almost unknown. It’s a bit subtle; first, we’ll add a watch for which returns the object instance representing the current thread. Thread.currentThread() As you can see, I can see the current thread in the watch. Now, I can run this method again and again and see the current thread; is the method always executed from the same thread? Well, I can look at the thread ID, and yep. It’s the same. So, it’s probably thread-safe. But how can I verify this? I usually write down the object ID or the pointer of the variable on a piece of paper and check if it’s the same value. That’s a pain and doesn’t scale. How often can I press continue again and again? In the right-click menu, I select Mark Object and type in an arbitrary name. in this case, once I did that, I can press OK MyThread This replaces the value of the current thread right now with the new label. So, we might incorrectly assume that this is just a name for a watch expression. It isn’t. We declared a new variable and gave it the name . MyThread We copied the current value of the watch expression into that variable. We can now treat that variable as we treat most variables in the IDE. We can evaluate the value here and get everything we want. Notice the suffix added by IntelliJ to avoid naming collisions but other than that, we can invoke any operation on this object such as get the name or even access the private field name. _DebugLabel But this gets much better… Let’s add a breakpoint to this method, a completely standard breakpoint like we did before. This will be a standard conditional breakpoint; we’ll discuss those soon enough in-depth, but right now, all you need to know is that I can define a condition that will determine if the breakpoint will stop or not. Let’s zoom in. Let’s type in the condition; I can compare to the current value of the thread. Notice that this condition will behave accordingly since the value of is independent of the original watch statement of . MyThread MyThread Thread.currentThread() So, if the current thread is indeed different the breakpoint will stop at this point. This is immensely useful when dealing with many objects. In this case, I can literally check if the method will be hit with the same thread. I can use it to compare any objects instead of writing their pointers on a piece of paper! Yes. I would literally sit with a piece of paper and copy the pointer address to make sure I got it right if I see it again. This is better in so many ways! I often use this with APIs like JPA where we might sometimes have two object instances with the same identity. This is really hard to detect. Just mark one object, and then you can instantly see it’s a different instance. Since this case is obviously single-threaded, the breakpoint will never get hit again. But this works rather well for very elaborate cases and is a remarkably useful tool! Finally Next up, we will dive deep into breakpoints and the amazing things they can do. This is a deep-dive video that you don’t want to miss. If you have any questions, please use the comments section. Thank you!

Too Long; Didn't Read

Making security fun one episode at a time

Debugging Like a Senior Developer: Watch And Evaluate

Too Long; Didn't Read

Shai Almog

About Author

TOPICS

Languages

THIS ARTICLE WAS FEATURED IN...

Debugging Like a Senior Developer: Watch And Evaluate

Too Long; Didn't Read

Shai Almog

About Author

TOPICS

Languages

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES