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.)