ExchangeHandler instances can definitely block/intervene in the processing of a message. Check out the policy handler for an example - if policy requirements are not met, the handler rejects the exchange.
In the case of an error, replying with a fault is appropriate. You can do this via sendFault() or by throwing a HandlerException.
In the case of a normal reply (e.g. a cache), you should call send to reply.
Sounds like there may be a bug based on the stack trace above. If you can submit a test case or app that reproduces the behavior that would be great.
Looks like the master no longer has this problem - the correct fault string is now passed to the SOAP client.