At the moment I've been using logging to keep a track of my continuously changing values within an update loop. Problem is is that this can be time consuming.
I can use the debugger but it stops code executing and due to what I'm doing causes weird results and false values.
Does anyone know if it's possible to "watch" the variables while keeping the code running. Like having one watch within a scope.
Android Studio/IntelliJ have some really nice features in breakpoints that let the IDE take an action when it hits a breakpoint instead of just dropping your app into the debugger (which it can of course also do). On any given breakpoint, there's a checkbox in the options that controls whether it will actually suspend your app and drop it into the debugger; you can turn that on or off independently. You can have it log a message to the debugger console, or have it evaluate any expression and log the results to the console.
I find these options super-handy; it's the equivalent of adding debug logging to your code, but you can add and change it on the fly without modifying your code and doing a rebuild-restart cycle.
There's also some really powerful filtering that will selectively control whether or not the breakpoint is triggered based on certain criteria; you can even set up cascades of breakpoints where one doesn't fire until a previous one is hit.
Experiment with some of the options.
Related
Sometimes you need just to check how are some values in your application changing in time. Usually, you can use the log, but imagine that your application is on severs already and make the whole CI/CD cycle, just to add a few temporary log statements is overkill. Or variables are in 3-rd party libraries, and you don't want to patch it.
Of course, you can (remotely) debug your application, but it may be an issue to suspend the thread and check several variables again and again and again.
Such functionality is available in the JetBrains IntelliJ IDEA out of the box - tracepoint, but what about Eclipse?
Fortunately, you can implement the "virtual logging" with Eclipse.
To do it:
Start the debug session
add the conditional breakpoint to the line that you want to add a log statement
Write the log statement to the breakpoint condition and return false;
That's all. The application will not suspend while passing breakpoint but will write to output the value of the variable
I’m confused by the Debugger. It seems to pause the app and show the Debug window for some breakpoints and not for other breakpoints. It still ticks the breakpoints, though it doesn’t pause the app. And when I open the Debug window I see no frame so I couldn’t look at variables. I’ve looked at many documents and they haven’t cleared my problem. So what I’d like to know are:
how frame and thread are related
does breakpoint work differently in different place or different class in the app?
As it seems the Guide provided by Google doesn't answer your question, I will add an extra explanation, hope it helps:
1- The Frame is directly related to application process which can be consisted of multiple thread used by application, means that as long as application process is up and running the frame is available too.
However this doesn't mean that you can watch variables whenever you want, the Variables window frame become available once the debugger hits a breakpoint.
2- Yes, for the debugger to hit a breakpoint few criteria should be met. It's a long list but here is the more important ones:
App must be debuggable in the first place, if the app is defined as
not debuggable (like release builds) then the debugger won't work.
The code must be readable hence executable to debugger, that means codes that are obfuscated or tampered with won't cause the debugger to stop at breakpoints..
Code must be executable, that means codes that aren't executable like variable declaration or codes that are unreachable won't cause debugger to stop.
P.S: Of course these are only few major causes and there are lots of others like instant run that can make a piece of code undebuggable.
I use Drag method on a Java Slider with some number as argument. It fails to work during execution. But always works with breakpoint. Any setting to make QTP simulate execution behavior of breakpoint.
Please note that application is thick client Java.
I've come across this problem in the past and I found it was because QTP/UFT was getting ahead of its self. This might seem primitive but I had a sync (to ensure that your application has displayed the expected page), put a couple of second wait, check that 'Slider' exists and then attempt an action on it.
Is it possible to have Eclipse execute an arbitrary expression at a particular point in code when debugging?
The Execute/Display functionality allows you to run arbitrary code in the context of debugging. A breakpoint stops flow.
What I'd like is something like a breakpoint that can be inserted at a particular point in a class, doesn't suspend application flow, but instead executes a snippet of code.
The background is I'm trying to debug some multithreaded code which I can't edit, and I want to do some naive System.out.printlns to see when various things happen. If I use breakpoints then the flow of the events will be disturbed.
Aha! There's an undocumented feature whereby conditional breakpoints can execute other code, dubbed 'Printpoints'.
You may use the "Breakpoint Properties" of a breakpoint to add some code. Hit the "Conditional" Checkbox in the dialog and place your code there.
Say I want execute some custom Java code for when a user adds or removes a breakpoint. I know that the normal way is handle this within eclipse's org.eclipse.debug.core framework, but I am not currently doing that. I have a custom debugger which uses none of that, currently. Is there a way to to (1) listen for events of added and removed linebreaks and (2) gathering all current linebreak markers when eclipse is started (synchronizing them to the custom debugger) ?
one way to do it is to get BreakpointsView and get it from there using reflection