Tom Ball's Blog

Exceptional Debugging

• Overly general exceptions: although you don't need a separate type for all possible exception cases, it is often very useful to do more than "throw new InternalError()" when a problem arises. The java.io package derives FileNotFoundException and EOFException from IOException, since for many apps these are much more common recoverable error conditions than, say, a SyncFailedException. A custom exception is a great documentation aid if you have a public API, and exception classes are simple to create and maintain.


• Using exceptions for flow control: as Josh Bloch argued in Effective Java, "Use exceptions only for exceptional conditions" (item 39). In the Solaris JDK a few years back, for example, system font files were discovered by trying to open all possible font names and catching all the FileNotFoundExceptions. This was much slower and more memory intensive than using File.exists(), due to all the exception object creation and collection. If your program is querying a class by poking it and testing for exceptions, add a method to that class to get the information directly.

Comments

• Hi There,

  I'm one of those guys who was looking for Breakpoint on Exceptions (since I came from using WinICE/SoftICE BPINT, etc-- for that matter, Visual Studio/Windows SDK had something equivalent called DebugBreak()).

  When I use Eclipse to set breakpoint on java.lang.Exception, I hit a lot of exceptions in the java RTL. I wish IDEs had a way of saying, only break in my code and not in someone else's code(including library). I guess, for that happen, the JVMTI interface should help the IDEs.

  Also, it would be great if IDEs had the feature like Visual Studio/Windows SDK' DebugBreak(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/debugbreak.asp) where if the code hits an exception, the RTL will launch a DIALOG enabling the foreground user to launch an IDE to debug the application. Such a feature will be really cool for Swing applications and command-line applications. I'm not sure how useful it will be for server based applications -- perhaps an IRC message with a link that will launch a remote-debug session ?

  BR,
  ~A

  Posted by: anjanb2 on April 04, 2005 at 06:44 PM

• anjanb2, some good Java debuggers do allow you to 'filter' out classes from packages you didn't write. For example, IntelliJ's debugger allows you to set exception breakpoints, yet ignore the breakpoint if it gets trapped in a class you've excluded.

  tball, how about Class.forName() as a prime example of control-flow-via-exception? We need the equivalent of file.exists() in that context.

  Posted by: dtbullock on April 05, 2005 at 01:40 AM

• >I wish IDEs had a way of saying, only break in my code and not in someone
  >elses code(including library).

  With Eclipse, you could use the filters for Breakpoints; on an Exception Breakpoint open its Filter settings (available from the popup menu on the Exception Breakpoint); here you can restrict the exceptions to a particular thread and to individual classes and packages.

  Posted by: murphee on April 05, 2005 at 04:55 AM

• Thanks for pointing out this feature. I was looking for this for a long time.

  Posted by: mnuhoglu on April 05, 2005 at 07:21 AM

• NetBeans supports conditions on breakpoints today, but the filtering options described above sound like good enhancements.

  A Class.classExists() method would be a useful enhancement to avoid using Class.forName(), but you can write that in your own code:

  public boolean classExists(String name) {
  return getClass().getResourceAsStream(name) != null;
  }

  Class.getResource() is more efficient (a URL is returned instead of the file being loaded into an InputStream), but some SecurityManagers (like applets) will not allow this operation since the URL might disclose network configuration details.

  Posted by: tball on April 05, 2005 at 09:05 AM

• Really good suggestion! I added this NullPointerExcpetion breakpoint in my WSAD, I just got so many exceptions in WSLauncher class. I have disable it to allow the server up.

  Posted by: libo_tsinghua on April 05, 2005 at 09:13 AM

• Maybe it's time to switch application servers. ;-)

  Posted by: tball on April 05, 2005 at 09:35 AM

• 
  public boolean classExists(String name) {
  return getClass().getResourceAsStream(name) != null;
  }

  
  Should be

  public boolean classExists(String name) {
  String resource = name.replace('.','/') + ".class";
  return getClass().getClassLoader().getResource(resource) != null;
  }

  
  Notes:

  appended ".class", because we are looking for a *.class resource.
  used ClassLoader.getResource() because Class.getResource() can succeed for unqualified names in the same package which then fail when Class.forName() is called.
  used getResource() not getResourceAsStream() to avoid the overhead of opening the resource, and avoid potential problems with not closing it afterwards.
  

  Posted by: brucechapman on April 05, 2005 at 06:12 PM

• Thanks for the code improvement -- this will teach me to pull examples from working code (such as how java.beans.Beans does it) instead of memory!

  Posted by: tball on April 06, 2005 at 07:36 AM

This work is licensed under a Creative Commons License.