11

I am using a third party library in my Java application. This third party library throws a custom uncaught exception at every application startup. The exception is harmless and only used for logging purposes internally to the third party library. Since this exception is not caught it causes my Eclipse IDE to switch into the debug perspective and suspend the thread execution everytime I start the application to inform me of the issue. I have to manually tell Eclipse to ignore this and just resume debugging every time. This is very annoying. I cannot change the third party library in order to fix this issue.

Is there a way to tell the Eclipse IDE to ignore a specific type of uncaught exception?

I tried "Step Filtering" but (I think) since the custom uncaught exception is not in the stack trace it is not being filtered out from the debugger. This is my first foray into Step Filtering so I could be using it wrong. Here is a sample stack trace.

Daemon Thread [Thread-13] (Suspended (exception CustomThirdPartyException)) 
    ThreadPoolExecutor$Worker.run() line: not available [local variables unavailable]   
    Thread.run() line: not available

EDIT:

jluzwick's work around of using our own logger to watch for uncaught exceptions after disabling all uncaught exceptions in Eclipse could technically work but it is not ideal and it's possible we could miss things if our logger is broken.

mazaneicha's Solution seemed to be on the right track but I could not get it to work exactly the way I wanted. This may be due to user error on my part.

jluzwick and mazaneicha both had possible work arounds to this issue but Konstantin Komissarchik had the "correct" answer in that this should be pushed back to the library's creators to fix. Sometimes a technical solution is not the right one.

Tansir1
  • 1,789
  • 2
  • 15
  • 28

6 Answers6

14

An old thread, but figured I'd add a bit to it.

In at least Eclipse Indigo: In the Debug Perspective->Breakpoints view:

  1. Specify a breakpoint for Exceptions (and potentially subclasses) you want to pause on. This is done by clicking the "Add Java Exception Breakpoint". An icon that is a J and an exclamation point.
  2. Right click the breakpoint and select "Breakpoint Properties"
  3. Go to "Filtering"
  4. Specify the Class or Packages you want to ignore. This will add them to the list. Just be sure to uncheck them to delineate that it's exclusive (do not stop in the specified location)

I tend to use this so that I can specify NullPointerExceptions as a general exception breakpoint, but ignore packages that are from third party libraries.

Jeff
  • 156
  • 1
  • 2
  • in my opinion this is a better answer than the selected one. i will note that i didn't have very good luck excluding by "class" and instead had to resort to using "package"-based exclusions (Eclipse Galileo). thanks @Jeff! – Matt Felzani Jun 21 '13 at 12:56
  • "An old thread [...]" So what? Stop giving a damn about the idiotic whines you may get when you contribute something USEFUL, VALUABLE to an old discussion. – async Dec 05 '14 at 10:27
2

I would recommend trying to solve this in code instead. Find the place in your code where you are initializing this library and catch this exception instead of letting it propagate up the stack, which is not considered "normal" behavior.

Konstantin Komissarchik
  • 28,879
  • 6
  • 61
  • 61
  • 3
    The library spawns its own thread pool where this exception occurs. I can't just wrap the library initialization in a try/catch. I have no control over the call stack where the exception occurs. – Tansir1 Mar 01 '11 at 18:50
  • 1
    You have a problem then. I recommend contacting the library provider and reporting a bug. Even if you configure your debug session to ignore this problem, it will still be there at runtime/production. You cannot tell Eclipse runtime to ignore uncaught exceptions. They go straight to the error log. – Konstantin Komissarchik Mar 01 '11 at 18:53
  • 4
    This is splitting hairs, but you can tell Eclipse to ignore ALL uncaught exceptions. I was hoping to find a way to ignore one specific type. It can be done by going to Windows->Preferences->Java->Debug and unchecking "Suspend execution on uncaught exceptions." This is a very very bad idea but it can be done. I didn't think I had any options but I thought it couldn't hurt to ask on here. Thanks for the help. – Tansir1 Mar 01 '11 at 19:01
1

Have you tried this?

Go to Window->Preferences->Java->Debug

Under "Suspend Execution" uncheck "Suspend Execution on uncaught exceptions"

I'm not sure there's a way to disable for specific exceptions, but I could be wrong. There might possibly be a plugin that does it.

jluzwick
  • 2,005
  • 1
  • 15
  • 23
  • As you said it doesn't work for specific exceptions. That causes Eclipse to ignore them all. I still want it to catch everything else in order to find issues in my own code. – Tansir1 Mar 01 '11 at 19:05
  • @Tansir1 your uncaught exceptions will still be reported through your logger though correct? If you notice one of your own exceptions being thrown, you could setup a break-point where it's being thrown from. – jluzwick Mar 01 '11 at 19:07
1

In Debug perspective, Breakpoints view, click on Java Exception Breakpoints (an icon with small letter J and exclamation mark, J!). In the appearing Add Java Exception Breakpoint window, you can find your annoying exception and uncheck "Suspend on Uncaught Exception" box.

mazaneicha
  • 8,794
  • 4
  • 33
  • 52
1

Contributing to Jeff's answer:

In Debug perspective right click on the suspended thread and choose 'Exclude Exception Location'. This way Eclipse adds the class the thread suspended on to the filtering list of the uncaught exception.

Aron
  • 11
  • 1
0

You sound like you need a simple try , catch.

 MyException e = new MyException;
 try {
       throw new e;
 } catch (MyException e) {
       e.printStackTrace();
 }

This will allow the exception to be thrown, yet will ignore and let the program continue. If you want it to be logged to a file, use 'PrintWriter.println(e.printStackTrace());'

I hope you got what you needed, and happy coding!

Galen Nare
  • 336
  • 1
  • 2
  • 9
  • See comments to Konstantin Komissarchik's answer. I had no control over the call stack so I couldn't just wrap the exception like that. It was in a 3rd party library, not my own code. – Tansir1 May 18 '13 at 23:15