2 Replies Latest reply on Jul 12, 2006 1:10 PM by Scott Stark

    Use of Throwable in method signatures

    Scott Stark Master

      The use of Throwable in a number of the mc signatures causes integration issues with other apis that only expose an Exception. For example, the BeanDeployer initialization of the BasicXMLDeployer in start is going to have to catch a Throwable and cast it to either an Error subtype or Exception subtype:

       /** Overriden to initialize the BasicXMLDeployer
       */
       @Override
       public void start() throws Exception
       {
       kernelDeployer = new BasicXMLDeployer(context.getKernel());
       super.start();
       }
      


      In the case of an actual Throwable being seen it will have to be wrapped. Can we just use Exception as the base throws signature in the mc?


        • 1. Re: Use of Throwable in method signatures
          Adrian Brock Master

          I made the signatures Throwable because I wanted to
          make sure I was dealing with Runtime exceptions in the core code
          properly.

          One of the failings of the current JMX Microkernel (something
          I've continually tried to fix when people break it) is that it doesn't
          properly deal with callouts that throw NPE, etc. and you
          end up with a broken state machine that can only be recovered by
          rebooting.

          The example you show doesn't look like it needs to fall in this
          category?

          • 2. Re: Use of Throwable in method signatures
            Scott Stark Master

            The Throwable just results in is a boilerplate code block like the following that does not actually require handling of the runtime errors:

             try
             {
             kernelDeployer = new BasicXMLDeployer(context.getKernel());
             }
             catch(Error e)
             {
             throw e;
             }
             catch(Exception e)
             {
             throw e;
             }
             catch(Throwable e)
             {
             // Should not happen
             throw new Exception("Failed to create BasicXMLDeployer", e);
             }
            


            This still does not really solve the problem you are after as I have ignored the runtime exceptions/errors as before. It seems what we really need is a KernelAction wrapper similar to a PriviledgedAction that integrates with the caller's kernel state to ensure exceptions are properly reflected in the state machine. I don't see how to force use of this though.