According to JAX-WS specification, if a runtime exception is thrown by a web service endpoint implementation and the message exchangepattern warrants a response, then a SOAP fault will be generated and, eventually, it will result in a javax.xml.ws.ProtocolException, or a subclass thereof, on the client side. Actually, if you are doing SOAP, the exception will be a javax.xml.ws.soap.SOAPFaultException exception.
If you want to do something on the server side when an exception occurs, there are two options, as far as I know:
1) Use Java exception handling and catch runtime exceptions originating from the processing layer of the web service in the interaction layer and do what you have to do.
2) Use a handler and do what you have to do in the handleFault method.
Note that handleFault will be invoked for all faults, both those originating from service-specific exceptions and those originating from system exceptions (in which runtime exceptions are included).
I agree with Ivan. However, from the design perspective, I would like to ask you this: Do you want to handle runtime exception on the service side or the client side?
RuntimeException means an exception that you aren't aware of at the design time e.g. NullPointerException. You should not handle any specific runtime exception on the client side. Ideally, the client should only handle the faults that are explicitly defined in the WSDL. For an explicitly defined fault, appropriate Java code will be generated on the client side so that you can handle the fault. If you have a requirement to handle other faults, use ideas suggested by Ivan. Ivan's suggestions can also be used to handle explicit faults (those defined in the WSDL).
If you are talking about the service side, ask yourself, why do you want to handle a runtime exception? Is that because you don't want to send any unknown exception in the SOAP response? If yes, you should design a fault mechanism with some kind of code. On the service side, you should catch Exception, set appropriate code and throw the exception so it gets converted into a fault defined in the WSDL.
Morale of the story is, stick to the faults defined in WSDL. Use fewer faults because in web services world, the client and the service are quite disconnected so you don't want your clients to have to know about bunch of faults. And finally, agree on a fault code/message mechanism to indicate different error responses (similar to what a browser does: response code 200 for OK, 404 for not found, 500 for server error etc.)