Use of Throwable in method signatures

[starksm64]

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?

[adrian.brock]

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?

[starksm64]

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.