In the debugger, how to ignore exceptions that never pass through my code

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

4 comments
Comment actions Permalink

there is nice exception breakpoint support:
- create breakpoint
- right-click on red-bullet
- choose 'Properties'
--> you will see some options under the tab 'Exceptions'

0
Comment actions Permalink

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<Integer> list = new ArrayList<Integer>();
 
 list.remove(0);


which gives the following stack trace:

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
 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
2
Comment actions Permalink

I proposed this answer for you on SO

You can define a

condition
on an
exception
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
getStackTrace()
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.

0
Comment actions Permalink

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 ArrayList item 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.

8

Please sign in to leave a comment.