Add default conformance of ResponseGenerator for HTTPResponseError

[sidepelican]

This is one of the solution of #501.

Add default conformance of ResponseGenerator for HTTPResponseError

[codecov]

Codecov Report

Attention: Patch coverage is 88.88889% with 1 line in your changes missing coverage. Please review.

Project coverage is 83.04%. Comparing base (e78cde7) to head (dd8381e).
Report is 94 commits behind head on main.

Files	Patch %	Lines
Sources/Hummingbird/Error/HTTPResponseError.swift	88.88%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #502      +/-   ##
==========================================
- Coverage   84.86%   83.04%   -1.83%     
==========================================
  Files          98       95       -3     
  Lines        5320     4287    -1033     
==========================================
- Hits         4515     3560     -955     
+ Misses        805      727      -78     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[adam-fowler]

This could be an alternative to what we have. I’ll need to have a think about it.

[adam-fowler]

Given you have provided a default implementation here, HTTPError won't output any errors now.

[sidepelican]

My hope is that HTTPResponseError will become a utility to easily convert its own errors into a Response, similar to Vapor.AbortError.

If ideologically it is not right to do so, I can accept that.
However, HTTPResponseError is confusing, so I would prefer it not to exist.

If you stop converting HTTPResponseError in RouterResponder and convert it in a new Middleware instead, there would be no need to handle HTTPResponseError in TracingMiddleware (Sorry this is just idea).

[adam-fowler]

My hope is that HTTPResponseError will become a utility to easily convert its own errors into a Response, similar to Vapor.AbortError.

If ideologically it is not right to do so, I can accept that. However, HTTPResponseError is confusing, so I would prefer it not to exist.

If you stop converting HTTPResponseError in RouterResponder and convert it in a new Middleware instead, there would be no need to handle HTTPResponseError in TracingMiddleware (Sorry this is just idea).

HTTPResponseError is a protocol you conform your error to, if you want to generate a response from that error. It doesn't require a definition for the error body as it could come in many forms, a string, buffer, object. How you generate a response from that is defined in your implementation of response(from:context). Also the response generated by the error should be in the format expected. If the response encoder outputs XML then the error should be in XML, so you need the request headers (at least the accept header) and request context to be able to generate the correct payload and augment the headers with content-type.

[sidepelican]

Ok. HTTPResponseError is not the utility I thought it was. I can agree with the design approach, so I will close this PR. Thank you.