Better InvalidResponse / ErrorResponse messages?

[bhudgeons]

In a complicated API, even when handling errors explicitly, there are times when you still get a stacktrace like the one below, which doesn't help you find the error (especially in complicated workflows where the exact call that failed is hard to determine):

featherbed.request.ErrorResponse: Error response received
	at featherbed.request.RequestTypes$RequestSyntax$$anonfun$featherbed$request$RequestTypes$RequestSyntax$$handleRequest$1.apply(RequestSyntax.scala:123)
	at featherbed.request.RequestTypes$RequestSyntax$$anonfun$featherbed$request$RequestTypes$RequestSyntax$$handleRequest$1.apply(RequestSyntax.scala:84)
	at com.twitter.util.Future$$anonfun$flatMap$1.apply(Future.scala:1089)
	at com.twitter.util.Future$$anonfun$flatMap$1.apply(Future.scala:1088)
	at com.twitter.util.Promise$Transformer.liftedTree1$1(Promise.scala:107)
       ...

At least InvalidResponse includes the reason in the message, but ErrorResponse is a complete black box if it gets thrown in a place you didn't explicitly handle it.

I'm wondering if some information from the Request and/or Response might be helpful in constructing the message (here), or if you have other suggestions on how this might be made easier (without wrapping all code in try-catches).

I'm happy to help with implementation, but wanted to see if there was a better way to handle this before I dove in.

[nicosuave]

I think adding status code to the message would be appropriate, especially given that's the determinator of an ErrorResponse

featherbed/featherbed-core/src/main/scala/featherbed/request/RequestSyntax.scala

Line 84 in 6ef558e

rep => rep.status match {

[nicosuave]

I am happy to contribute, @jeremyrsmith – just not sure exactly where you are w/ #61