Exception RuntimeFault is not a subclass of Throwable

[mamm201110141]

Hi all! A search found nothing, so here I am.

In the lastest version of vim25.jar (from VMware-vSphere-SDK-5.0.0-429209.zip), the exception class RuntimeFault is a subclass of MethodFault; MethodFault is a (implicit) subclass of Object, and here the hierarchy obviously ends. RuntimeFault doesn't follow the "traditional" hierarchy of an exception (NewUserException -> Exception -> Throwable -> Object), so RuntimeFault IS NOT Throwable.

So how are you supposed to throw/catch RuntimeFault (or one of its subclasses: DatabaseError, ManagedObjectNotFound, SystemError, etc)? If you try throw/catch it, you get "No exception of type RuntimeFault can be thrown; an exception type must be a subclass of Throwable".

How can (for instance) VI Java API - http://vijava.sourceforge.net/ - make extensive use of throwing RuntimeFault around? Case in point: com.vmware.vim25.mo.InventoryNavigator.searchManagedEntity(String, String) can throw a RuntimeFault exception. How does that even compile?

What am I missing here? Thanks in advance!

Marco Melo

Developer at Virtos Backups - virtos.com

[BenN]

VI Java doesn't use the SDK, that's why. It is essentially a custom built SOAP client library for the SOAP messages supported by the vSphere API. So it has its own RuntimeFault class that it instantiates from a received SOAP fault, and that class has nothing to do with the RuntimeFault class distributed in the SDK.

Secondly, note that the SDK has multiple RuntimeFault classes, because it includes both Axis and JAXWS WSDL-to-Java mappings. Each maps the WSDL a little differently. The Axis mapping does make RuntimeFault an Exception (via AxisFault), whereas the JAXWS doesn't but has another RuntimeFaultFaultMsg class which is.

I won't pretend to understand the reasons for the various mappings. I use VI Java happily and ignore the SDK.

[mamm201110141]

Thanks, Ben.

"I use VI Java happily and ignore the SDK."

I'm beginning to think that that's the way I should do too. Problem is that VI Java only "reimplements" a subset of the SDK - what you do when you need something from the SDK which is not included in this subset?

[BenN]

A good question, that I don't have a good answer for. So far I haven't encountered anything missing, and Steve (the author of VI Java) has updated it for new vSphere releases sooner than I've updated my dev environments. Not sure if that will continue now that he no longer works at VMware.

In a pinch: extend VI Java myself, since it's open source.

For larger changes, or if I started to have misgivings about VI Java's future: probably have to choose one of the WSDL mappings in the SDK.

[mamm201110141]

Thanks again, Ben. According to his last posts, Steve seems to be keen on continuing the development of VI Java (and is looking for contributors).

I think VMWare is missing out big time by not supporting VI Java...