Serverside JAX-RPC message handlers are only supposed to throw a
javax.xml.rpc.soap.SOAPFaultException (or a subclass) from the handleRequest message mainly because the exceptions thrown by handlers are supposed to be related to the SOAP headers not the SOAP Body. SOAPFaultException features the standard parts of a SOAP Fault: detail, faultactor, faultcode (e.g. {http://schemas.xmlsoap.org/soap/envelope/}Client. {http://schemas.xmlsoap.org/soap/envelope/}Server, {http://schemas.xmlsoap.org/soap/envelope/}VersionMismatch, {http://schemas.xmlsoap.org/soap/envelope/}MustUnderstand), and faultstring.
Now some SOAP stacks like Axis 1.x will place java exception related information into the FaultString. e.g.:
You could adopt a similar tactic by providing a customized fault
string when you create a javax.xml.rpc.soap.SOAPFaultException.
However an "InvalidDataException" is clearly an application exception and therefore should be part of the service contract (WSDL) - it should be thrown by the implementing web service method, not a handler. Each operation that can return an "InvalidData" fault should declare it in the WSDL. Furthermore you can then define the structure and types of the "InvalidData" fault message in the WSDL types section through XML schema. Once you have done that the WSDL-to-Java generator will generate a Java "InvalidDataFaultException" that can be used by the implementing web service method so that it can throw the exception (fault) when necessary.
Now as the service all you have control over is the (XML) SOAP fault that the client will receive. You have absolutely no control over the exception that it will be mapped to. That is up to your client, their SOAP stack and its configuration.