I have a simple Java class Fraction with chained constructors
public class Fraction {
private int numerator;
private int denominator;
public Fraction(){ // no-arg constructor
-> setNumerator(0);
setDenominator(0);
}
public Fraction(Fraction f){ //copy constructor
-> this(f.getNumerator(), f.getDenominator());
}
public Fraction (String sFraction){ // String input constructor
-> this(sFraction.split("/")[0], sFraction.split("/")[1]);
}
public Fraction(String sNum, String sDenom){ // Double string constructor
-> this(Integer.parseInt(sNum), Integer.parseInt(sDenom));
}
public Fraction(int iNum, int iDenom){ // two int constructor
-> this.setNumerator(iNum);
this.setDenominator(iDenom);
}
}
And I have breakpoint on first line of each constructors (Marked by ->). Now if I stop at a breakpoint in one of the constructors and hit "Step Return" in Eclipse IDE, the execution stops at next chained constructor breakpoint, instead of returning back from the constructor. I don't understand this behavior. I thought Step Return should complete execution of the method and return. Then why is it hitting the breakpoint in the next chained constructor?
See explained details about Step Return just below.
All active breakpoints will produce a debug cursor stop, no matter if you do resume, step into/over/return. The cursor will be stopped where you have an active breakpoint and the code will execute. (And from my perspective) I would say thank God it does it. Sometimes you add your breakpoints all over the code as you are not really sure where the smell is/come from ;)
It is more simple to "Skip all breakpoints" when you don't need the stops. There is a CTRL+ALT+B shortcut to toggle this function between skip all breakpoints. Or just disable the points one by one when you don't need them.
More details can be read here.
The differenct debug execution steps are:
Resume
Resumes a suspended thread.
(To resume the execution of the currently suspended debug target.)
Step Into
Steps into the highlighted statement.
(To step into the next method call at the currently executing line of code.
To step into a method you must have execution suspended and be stepping through code.)
Step Over
Steps over the highlighted statement. Execution will continue at the next line either in the same method or (if you are at the end of a method) it will continue in the method from which the current method was called. The cursor jumps to the declaration of the method and selects this line.
(To step over the next method call (without entering it) at the currently executing line of code. Even though the method is never stepped into, the method will be executed normally.
To step over a method you must have execution suspended and be stepping through code.)
Step Return
Steps out of the current method. This option stops execution after exiting the current method.
(To return from a method which has been stepped into. Even though we return from the method, the remainder of the code inside the method will be executed normally. To step return from a method you must have execution suspended and be stepping through code.)
Suspend
Suspends the selected thread of a target so that you can browse or modify code, inspect data, step, and so on.
(To halt the execution of the currently selected thread in a debug target. Once the selected thread is suspended you can then examine its stack frames.)
Terminate
Terminates the selected debug target.
(To terminate the launch associated with the selected debug target. Once a launch is terminated it can be automatically removed from the Debug View. To change this setting use the Run/Debug -> Launching preference page.)
Terminate & Relaunch
Terminates the selected debug target and relaunches it.
(To first terminate the selected debug target and secondly, relaunch it. Once a launch is terminated it can be automatically removed from the Debug View. To change this setting use the Run/Debug -> Launching preference page.)
Terminate & Remove
Terminates the selected debug target and removes it from the view.
(To terminate the launch associated with the selected debug target and remove it from the Debug View.)
Terminate/Disconnect All
Terminates all active launches in the view.
(To terminate all the running debug targets in the Debug and Console View. If the target cannot be terminated, it will be disconnected. Once a launch is terminated it can be automatically removed from the Debug and Console View. To change this setting use the Run/Debug -> Launching preference page.)
Related
I tried to debug Parametrized Junit test (validateStockUpdateInventoryOperations) in InteliJ, but Step into is not working on breakpoint. When it reach at the breakpoint and I pressed step into. Debugger Jumps into org.powermock.api.mockito.internal.exceptions.StackTraceCleanerProvider class instead of jumping into my desired method (isValid(stockUpdateRequest, constraintValidatorContext)). Next time when I press next line it comes back to function from where it was instantiated (validateStockUpdateInventoryOperations).
I have a global variable
static int debugNumber;
and a breakpoint with a condition
debugNumber > 1
with Suspend thread, Conditional and Suspend when 'true' checked. Currently, if I pause the execution of the program and hover over the declaration the value displayed is 2. Still, this breakpoint doesn't break.
As far as I can see on Google and here at SE debugNumber > 1 should be fine. What am I doing wrong?
Just so we're clear: That line means: If code execution gets to this line (the line with the breakpoint), then do what breakpoints usually do: Freeze the thread (or if you've configured things to be that way, and pause all other threads, which is not the default). However, a conditional breakpoint means: Before breaking as usual, check the condition. If the condition is false, then don't do anything.
A conditional breakpoint is going to break as often, or less often, than a normal breakpoint, never more often.
It sounds like what you want is to 'breakpoint' every line in the codebase that sets the debugNumber variable, if the value it is being set to is 2 or higher. If that's what you want, make a 'watch' on debugNumber and configure the watch to break execution.
If that's not what you wanted, then, well, you made no mistakes in what you describes, so then it's one of a billion things that could be wrong:
The line with your breakpoint was never hit.
The debugNumber was 1 or less when it hit your breakpoint.
You used 'run' to start your application and not 'debug' (there's pretty much no reason to ever 'run' anything, always pick 'debug')
The global 'disable all breakpoints' toggle within eclipse has been toggled off. It's (unless you changed things) on the toolbar: a larger 'breakpoint dot' (blueish circle) with a big slash through it. It's a toggle button. Is it pressed in?
Eclipse debugger has desynced. It will throw you a dialog if this happens, but one of the options in this dialog is 'ignore now and in the future' (It's a more succint text than that, but that's the gist of it). If you ever pressed that, it can desync. The debug view will tell you. This can happen if you change compiled code as eclipse runs, or change signatures in your source files and save the source file in the middle of a run.
Many many more things
I have placed a breakpoint, but when I run the code in debug mode, it keeps skipping the breakpoints and I don't see any variables:
I'm new to this can someone help me out here, thank you.
You have somewhere a so-called trigger point that have to be hit first to enable the breakpoint in line 11.
Trigger points are decorated with a T and regular breakpoints are, if there are trigger points, decorated with a crossed-out T (like the breakpoint in line 11). In your case, with the trigger point not be hit the regular breakpoint will not become active and your program runs to the end without stopping at a breakpoint (terminated means finished and exit value: 0 means successfully).
To disable, delete or convert the trigger point(s):
Go to the Breakpoints view
Do one of the following with all trigger points (those decorated with a T):
Uncheck them to disable them
Select them and hit Delete to delete them
Select them one after the other and uncheck the Trigger Point checkbox to convert them into regular breakpoints
EDIT: I had originally believed this problem to have been caused by the ifPresentOrElse statement, however I now understand this is not the case and the infinite while loop is to blame for this behavior, and have renamed the question (see comments and chosen answer).
There is an existing question here that shares a similar behavior with this question, however I believe that the solutions are different enough for this not to be considered a duplicate.
Original Question:
Suppose I have a JavaFX application whose start method (in the Application thread) contains the following code:
while(true) {
new TextInputDialog().showAndWait()
.ifPresentOrElse(System.out::println,
Platform::exit);
}
The behavior of this should be that, if the OK button of the TextInputDialog is pressed (making a result present), the text entered within the dialog should be printed. If the CANCEL button is pressed, the Platform::exit statement will be called and the JavaFX application will exit.
The former case works as expected, however the latter doesn't. If the CANCEL button is pressed, the application stays alive and the dialog is opened again as if the OK button had been pressed, however no text is printed, which means that the Platform::exit statement must have been reached instead of the System.out::println statement. In an attempt to debug this issue, I adjusted the original code to the following:
while(true) {
new TextInputDialog().showAndWait()
.ifPresentOrElse(System.out::println,
() -> System.out.println("The latter statement has been reached"));
}
When running this code and pressing the CANCEL button, "The latter statement has been reached" is printed to the screen, proving that the Platform::exit was being reached in the original code, but was not closing the application as expected.
Interestingly enough, if I edit the original code once more to the following:
while(true) {
new TextInputDialog().showAndWait()
.ifPresentOrElse(System.out::println,
() -> System.exit(0));
}
...the program exits as expected.
I have never encountered a behavior like this before, and I am truly at a loss as to what is going on. Any insight would be greatly appreciated.
Read the documentation of Platform.exit():
Causes the JavaFX application to terminate. If this method is called after the Application start method is called, then the JavaFX launcher will call the Application stop method and terminate the JavaFX application thread. The launcher thread will then shutdown. If there are no other non-daemon threads that are running, the Java VM will exit. If this method is called from the Preloader or the Application init method, then the Application stop method may not be called.
This method may be called from any thread.
As can be seen, calling the method will not kill threads, so the thread running your while(true) loop will continue to run, and will prevent the program from ending.
You need to change the code so the while loop ends too, e.g. something like this:
AtomicBoolean keepRunning = new AtomicBoolean(true);
while (keepRunning.get()) {
new TextInputDialog().showAndWait()
.ifPresentOrElse(System.out::println,
() -> keepRunning.set(false));
}
Platform.exit();
I have a conditional break point set within a long loop. Here it is:
maBuyPeriod==55 && maSellPeriod==65 && quote.Symbol.equals("VAW")
Suspend is set to "Breakpoint thread".
In debugging mode, I can step over, step into, etc just fine. But when I click the Continue button, the debugging suspends on the current line without proceeding to the breakpoint.
This is NetBeans IDE 10.0. I have never been successful at getting conditional breakpoints to work. Suggestions?