catch (Exception ex) { }

Hi Dave,

Dave Makower writes:
 > It seems that there are exactly 241 places in the Jigsaw 1.0a5 source code
 > that catch the generic exception class Exception; quite a few of these
 > respond by doing absolutely nothing, not even a call to printStackTrace().
 > I realize that this is probably intended to keep the user/administrator
 > from being alerted in the case of several "normal" exceptions, but it has
 > the highly unfortunate side-effect of making Jigsaw resources very
 > difficult to debug.  If, for instance, Jigsaw resources trigger a
 > NullPointerException during presentation, Jigsaw often ignores this
 > completely.

Hopefully, there is an explanation to this :-)
A standard idiom in Java, when registering resource attributes is to
say:

public class Resource extends AttributeHolder {
    /**
     * Attribute index - The index for the identifier attribute.
     */
    protected static int ATTR_IDENTIFIER = -1 ;

    static {
	Attribute a   = null ;
	Class     cls = null ;
	// Get a pointer to our own class:
	try {
	    cls  = Class.forName("w3c.tools.store.Resource") ;
	} catch (Exception ex) {
	    ex.printStackTrace() ;
	    System.exit(1) ;
	}
	ATTR_IDENTIFIER = AttributeRegistry.registerAttribute(cls, a);
	// The resource store:
	a = new ObjectAttribute("resource-store"
				, "w3c.tools.store.ResourceStore"
				, null

This results in an uncatched exception, which you could get rid of (in
Java >= 1.1) by using:

Class cls = w3c.tools.store.Resource.class

My guess is that 90% of the 241 exceptions are of this kind. The
remaining ones, however, are indeed buggies (except in very special
cases) and should at least conditionally printStackTrace().

 > I'd like to suggest that someone take a careful look at all places in the
 > code where Exception is caught and ignored, and make a decision either to:
 > 
 > (a) print a stack trace, so that the error is reported even if no other
 > action is taken, or
 > 
 > (b) catch one or more specific subclasses of Exception
 > 
 > (c) distinguish between RuntimeExceptions and all others, so that
 > RuntimeExceptions are always reported, or at least re-thrown for the Java
 > interpreter to deal with.

I agree, the fix is to first fix the above cases, then redo the grep
and fix the remaining cases. My hope is that there is none of them ;-)

Anselm.

Received on Wednesday, 16 July 1997 05:59:11 UTC