You are right this is quite possible. However would you ever be able to deserialize it to the object type you passed? Perhaps it would be worth adding an error type to deserialize to in case of an error (possibly an extra parameter on the response object that swallows any exceptions if it couldn't deserialize to the provided error type). 

But in all other cases the only way I see this being use full is like this: you make a request, it fails with your desired return type passed. Subsequently you make the same request again with an error type passed as T to get a deserialized response. In the mean time that first call with it's failed deserialization is possibly obscuring the actual error that occurred (the invalid request). 

Personally I much more prefer it to only deserialize when it's getting back what it's asked for. Since you have access to the response data and to the exception/http status failing your call you then proceed to deserialize the error message if this is used by your application.

I understand your standpoint but I don't think just serializing a response that in 90% of the cases will fail and obscure the original issue is helpful. Any input how we might handle it more gracefully?