In Visual studio when an error happens during debug, the line causing the error is jumped to in the source code and the error displayed.
Is there a way with Elcipse to do the same? The Debug perspective appears, but the line causing the error and the error message are not immediately apparent.
I'm assuming you are working with Java, so the answer is yes. You can tell Eclipse to break on exception. From the Run menu, select Add Java Exception Breakpoint.... Now, you need to select the Exception class. If you wish to stop on all Exceptions, you can use java.lang.Throwable. You can also specify whether to stop on caught or uncaught exceptions.
You can (and should) also use it for assertions, as I outlined in this post.
Related
I'm debugging a normal Java application, no GUI, just a lot of computations and ~5 calls in the stack for the main thread when the problem occurs. Basically it keeps saying "Collecting data" in the local variable watch.
So instead of going step-by-step I've tried to add a breakpoint immediately after an press "Resume". Now it says "Waiting until last debugger command completes".
Have anyone had this problem before? Is changing the debugger the only way to figure this out?
On IntelliJ (2017.1.4 Community Edition), the following fixed the problem for me:
File->Settings
Type in "toString"
Navigate to Build, Execution, Deployment->Debugger->Data views->Java
Find the "Enable 'toString()' object view:" checkbox
Uncheck the box
Re-run the debugger.
The following fixed it for me on IntelliJ 2018.2.4:
Right click breakpoint
Toggle the setting to suspend "Thread" instead of "All"
This won't be helpful if you actually need to suspend all the threads for debugging, but it got rid of the "Collecting data..." and "Waiting until last debugger command completes" messages for me. The setting also persists for subsequent breakpoints, so you only need to change it once.
I just ran into what looks like the same issue. In my case it was a class (KafkaStream) in the breakpoint stack trace with a "bad" toString method. The toString method blocks and therefore hangs the debugger. I tested the toString method in the main line code and it hung the main thread (i.e. this is not a debugger specific issue).
Here is the stack trace for my thread that hit the breakpoint (on a line that was just trying to test a boolean attribute of my class):
Intellij provides a way to work around for my issue. It allows you to override how the debugger renders the class:
If your issue comes back I suggest taking a thread dump (inside or outside of the IDE) and see what your thread is doing.
In most cases, it would be because of the watches that you add while debugging.
Clear the watch statements that would result in recursive execution of same statements as in the code.
Always keep the watches clean before debugging.
It happened to me once (on version 2020.3.3) and "Invalidate Caches" and restart solved it.
The fix that worked for me was to remove method breakpoints. That made it superfast.
So I am debugging someone else's customized code used in a Java based enterprise software. As per his documentation, a specific file has the customization I am looking into. I deployed all customized files on the test server and now the browser window crashes as soon as it starts to render data using that code. No stack trace gets printed out. The customized code in question is not actually causing the issue. The issues is caused by some other code that uses the data returned from this piece of code. The puzzle for me is that I don't really know where the data is being returned to, and any error being thrown is not printed out. Is there anything I can do to figure out what file uses the data returned by this customized code?
Brute force: Tell debugger to break on all exceptions.
E.g. in Eclipse, select menu "Run" > "Add Java Exception Breakpoint...", type Exception and select the java.lang.Exception, check both "Suspend on caught exceptions" and "Suspend on uncaught exceptions", and click "OK". In the "Breakpoints" view, select the new Exception breakpoint and check "Subclasses of this exception".
This is break on any thrown Exception (not Error). You may see a lot of false positives, which is why I call this the "brute force" method.
Change to Throwable if you want to catch Error too.
I'm working in Java with Eclipse (Luna) and I would like to specify what action happens whenever my project throws an exception. In other words, anytime an error happens and Eclipse prints a stack trace to the console, I would like to run my own code to print the stack trace in my own debug window or save to a text file, for example.
I'm not sure if this is a problem for my java project (maybe by overriding printStackTrace()?) or for the IDE itself (through some setting, etc.) Either way it doesn't really matter since its just a debug feature and would be removed before I export anything public.
Thanks for your help
EDIT: To clarify, I'm not talking about exceptions only from a specific line/class. I'm familiar with try-catch blocks. What I want is to preform an action any time any exception or error happens anywhere in my code, even if there is a typo and my project wont compile.
NOTE: You cannot have your own debug window in IDE
If you want to log some of your exceptions to some file wherein latter on you can see, so its time you use log4j.
Start with this simple example.
You will find ample on google :)
I am having problems with debugging my code. One of my AsyncTasks throws a RuntimeException, but I don't know which line in my code is responsible for this. Since I am new to Eclipse and Java in general, all of this is rather confusing to me.
Eclipse's debugging window shows me that my AsyncTask has been suspended because of a RuntimeException. Below that, there are three lines which point out certain lines of code. However, those lines do not exist in my code which is why I do not know what causes my application to crash. Am I missing something essential about debugging in Java / Android?
These are the three lines which I am given, by the way:
ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1086
ThreadPoolExecutor$Worker.run() line: 561
Thread.run() line: 1096
How am I supposed to work with that? Help would be greatly appreciated.
in the ddms you can get the message related to the error, warning or other type of messages into the logcat window if you can't able to find the logcat in the ddms then go to the menu Window->Show View->logcat click on that and you'll be able to see the message now in the same ddms you also get the device window from that select the device for you can able to debug or get the message from that device into the logcat.
now check this way you can find your error detail into this logcat details
You're best using the logcat - this will show the stacktrace and the error raised. I've never had great success stepping through the code in DDMS but with the errrors shown in the logcat it's normally pretty easy to work out why the error was raised.
See Pratik's answer for opening the logcat if it isn't visible within Eclipse.
Rajeev got it right - when you set a breakpoint on an exception, the debugger will break on the line that throws it, not the line that catches it. In this way, you can see what is causing the exception.
When I start debugging a java project, Eclipse keeps on breaking at random exceptions in 3rd party libraries, and it's so annoying.
any idea how to stop this?
I tried clicking on the (!) icon on the Breakpoints view, I can see that both "Suspend on caught exceptions" and "Suspend on uncaught exceptions" checkboxes are not checked.. still Eclipse breaks on the exception.
Although I'm not sure I'm using this window correctly, am I meant to select the exceptions one by one? Or is there a way to specify all exceptions?
I had a similar issue with Eclipse stopping on uncaught exceptions and resolved it by going to Window - Preferences - Java - Debug and unchecking "Suspend execution on uncaught exceptions".
[Note: Not an answer to the exact question asked but highly related].
The exceptions you select with the "!" icon in the Breakpoint view are the exceptions you want to stop on. If you put "NullPointerException" in there and tell Eclipse to stop on "Caught and uncaught", your execution will stop on every last NullPointerException that gets thrown. Are you sure you haven't set a breakpoint on each of the "random exceptions" your execution stops on?