In the debugger, how to ignore exceptions that never pass through my code
Answered
Hi!
I've posted a question on Stack Overflow, asking whether it is possible to ignore Exceptions that never pass through my code (i.e. non-library code). Or how to break on exceptions at the point where they pass through my code instead of where it is thrown. I'm explaining the issue in great detail on Stack Overflow:
http://stackoverflow.com/questions/3335587/in-a-java-debugger-how-to-ignore-exceptions-never-passing-through-my-code
I'm reposting this question here, because I'm particularly interested in having this functionality in IntelliJ IDEA. If that's not already possible, I'll be happy to open a feature request with all your suggestions!
Thanks
Michael
Please sign in to leave a comment.
there is nice exception breakpoint support:
- create breakpoint
- right-click on red-bullet
- choose 'Properties'
--> you will see some options under the tab 'Exceptions'
In the Stack Overflow question I write: "I normally want to break on any exception, wether caught or uncaught, as long as code I've written is between the place it's thrown and the place it's caught", which means that I neither want to limit the exception by exception class nor by the class throwing it.
The main problem I want to solve is that when launching an application with the default "Any Exceptions" breakpoint turned on, I get about 30 or 40 hits before the main function is called. Maybe this just happens on my machine, but its pretty annoying. These are the different exceptions in that case (sort and uniq'd):
Exception 'java.lang.ClassNotFoundException' occurred in thread 'main' at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
Exception 'java.lang.ClassNotFoundException' occurred in thread 'main' at java.net.URLClassLoader.findClass(URLClassLoader.java:207)
Exception 'java.util.zip.ZipException' occurred in thread 'main' at java.util.zip.ZipFile.open(ZipFile.java:0)
Exception 'java.util.zip.ZipException' occurred in thread 'main' at sun.misc.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:634)
Exception 'java.util.zip.ZipException' occurred in thread 'main' at sun.misc.URLClassPath.getLoader(URLClassPath.java:338)
Exception 'sun.misc.CEStreamExhausted' occurred in thread 'main' at sun.misc.BASE64Decoder.decodeAtom(BASE64Decoder.java:100)
Putting those exceptions or classes in the filter list doesn't help, as there are other places that exceptions get thrown that my code never sees.
Something else I would like to do is to have the debugger always break on a line of code I've written, when there's an exception thrown in a library class I use. In the following, simple example an IndexOutOfBoundsException is thrown:
list.remove(0);
which gives the following stack trace:
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.remove(ArrayList.java:387)
at Main.main(Main.java:8)
The problem is much more probable to be on Line 8 in Main.java than in ArrayList's RangeCheck function, assuming I'm not debugging ArrayList ;-).
Thanks!
Michael
I proposed this answer for you on SO
You can define a
on an break point. The condition is just Java code executed at the time the breakpoint is hit, so the exception object would be in-scope during the condition check. You could call on the exception and decide if it is an exception that you are interested in by looking at each frame on the stack. If you aren't interested, then your condition fails, and the breakpoint is skipped.This is actually one of my biggest problems when debugging with IntelliJ IDEA, and there is still no solution for it.
Microsoft Visual Studio offers the option to break on exceptions "in my code only". This does not mean to ignore exceptions in other libraries; this means that if an exception is thrown in another library which I invoked, and it has not been handled by the time the unwinding reaches my code, then the debugger breaks in my code.
So, for example, if I invoke a library which then tries to access an
ArrayListitem that is out of bounds, the debugger breaks at my statement which invokes that library. But if the library catches the index out of bounds exception and returns to me as if nothing happened, then the debugger does not break at all. It is very elementary, and debugging is hell without this.And of course in properly written code, there is no such thing as an uncaught exception, so obviously, this feature needs to work even if the exception gets ultimately caught.
As Michael Belivanakis writes, this is abslutely crucial thing which works in Visual Studio, but not in Rider, I am paying customer, but I need to switch over to Visual Studio for this... :(
This is a huge pain point both when coding in Kotlin with IntellIJ and in C# with Rider.
Is there still no offical word or fix for this?
Please upvote https://youtrack.jetbrains.com/issue/IDEA-253949
To some extent this could be solved by using "catch class filter" on the exception breakpoint with your app package filter like "my.app.*". This way you'll stop only in catch blocks in your code.
In this case, it will only break if there _is_ actually a catch block… But even that doesn't work.
The notifications that I received regarding the comments above reminded me that this thread exists, so I will give you a link to a solution that I came up with a couple of years ago. (Many years since this thread was opened.)
My solution involves far more work than should really be necessary for such a simple problem, so a proper solution from JetBrains would be very useful.
Here it is: https://stackoverflow.com/q/71115356/773113
(Also note that I had to fight the IntelliJ IDEA IDE in order to accomplish one little part of my solution, which was to create a new exception breakpoint on `java.lang.Throwable`. A fix would be nice there, too, so that we do not have to fight the IDE when trying to work around other deficiencies of the IDE.)