Exception handling via response.exception

Actually that method above probably wont work, and needs to be more like this, tho I doubt it really matters for the purpose of this enhancement. I just wanted to correct it, as it was wrong

	        @Override protected Object doRequest(URI uri, Method method, Object contentType, Closure configClosure) {
		def delegateRequest
		def delegateResponse

		// hackish, but only way to gain access to the configClosure request & response objects
		def newClosure = {
			delegateRequest = request
			delegateResponse = response
			configClosure.delegate = delegate
			configClosure()
		}
		try {
			return super.doRequest(uri, method, contentType, newClosure)
		} catch (Exception e) {
			if ( delegateResponse.exception != null ) {
				delegateResponse.exception(e)
			} else {
				// we're expecting a response object in the exception
				HttpResponseDecorator httpResponse = e.response
				log.error("Exception occured in request to ${uri.path}/${method.toString()}")
				throw e
			}
		}
	}

Actually now that I look at it, I'm a little more leery of implementing this for a couple reasons...

1. you catch Exception but that's not always an instance of HttpResponseException. If it's not, {{

}} won't exist like you're expecting it to. doRequest throws ClientProtocolException and IOException as well.

2. re-throwing the exception from the catch clause re-writes the stack trace, hiding the original source of the error. The other option is to wrap the exception, but then it buries the cause just a little more.

(1) leads me to ask "do you want to pass all exceptions, or just exceptions after the response is retrieved?"

If you want to catch all exceptions, then it will always be wrapped, and in many cases response.exception might be null... Otherwise you are looking at some odd logic where in your own handler HttpResponseExceptions are not wrapped, but all other exceptions are... But if you don't specify a 'response.exception' handler, then all exceptions are wrapped purely to preserve the stack trace. I suppose there is probably some trickery I could do to preserve the stack trace of an already-thrown exception but that is only getting more convoluted.

In general, once you've learned the behavior of the server you're talking to, it should be fairly deterministic and you should know what to expect in terms of response content and manage to avoid ResponseParseExceptions in most cases.

What do you think? I'm not convinced this is a worth-while feature. That said your solution is not all that bad if you really want to handle exceptions that way.