Le jeudi 26 janvier 2017 07:42:55 UTC+1, JohnGB a écrit :
>
> Thanks Pierre, that looks like a simple and quite clean implementation.
> Although it's easier to use an iota for the numbering, does that open up
> any issues with keeping the documentation up to date? I know it's easier
> to program and extend, but it's also less obvious when codes change.
>
It's up to you. If you expect the codes to change a lot, then just list
them as constants.
>
> Is there a reason why you've used:
>
> var customHTTPErrorRegistry = map[errCode]customHTTPError{
> 1: {http.StatusOK, "OK"},
> }
>
> instead of say:
>
> var customHTTPErrorRegistry = map[errCode]customHTTPError{
> OK: {http.StatusOK, "OK"},
> }
>
>
No. The second option is better I think.
>
> On 25 January 2017 at 19:02, <pierre...@gmail.com <javascript:>> wrote:
>
>> Maybe use a map along the lines of: https://play.golang.org/p/YDF4q6cTyX
>> ?
>>
>> Le mercredi 25 janvier 2017 18:16:33 UTC+1, JohnGB a écrit :
>>>
>>> I have an HTTP API written in Go, and to give more fine grained
>>> responses to the client app, we return our own error codes along with the
>>> standard HTTP status codes Along a similar line to what Twitter does
>>> with its error codes
>>> <https://dev.twitter.com/overview/api/response-codes>. The correct
>>> HTTP status code can always be determined from our internal error code, so
>>> any HTTP handler that wants to return an error response, only has to call
>>> our error response function, and pass in our custom error code, and from
>>> that we can determine the error message and http response that we should
>>> give in the HTTP response. What I am not sure about, is the best way to
>>> structure this.
>>>
>>> One option is to define our error codes as constants with iota.
>>> Something like:
>>>
>>> const (
>>> OK int = iota + 1
>>>
>>> ErrBadRequest
>>> ErrRecipientNotExist
>>> ...
>>> )
>>>
>>> And then have some sort of switch lookup to return the HTTP response and
>>> the error message to return. Something like:
>>>
>>> func inspectStatusCode(errCode int) (httpStatus int, errorMsg string) {
>>> switch errCode {
>>> case OK:
>>> return http.StatusOK, "OK"
>>> case ErrBadRequest:
>>> return http.StatusBadRequest, "Poorly formatted request"
>>> case ErrRecipientNotExist:
>>> return http.StatusNotFound, "The entity does not exist"
>>> ...
>>> }
>>> ...
>>> }
>>>
>>> This method allows me to not have to directly specify an int value for
>>> each response.
>>>
>>> Alternatively I could define a struct that contains all of the data
>>> directly, but with an explicit response code. Something like:
>>>
>>> type response struct {
>>> code int
>>> message string
>>> httpStatus int
>>> }
>>>
>>> And then have a large number of global variables to reference the
>>> response. Something like:
>>>
>>> var (
>>> ErrBadRequest = errResp{
>>> code: 10,
>>> message: "Poorly formatted request",
>>> httpStatus: http.StatusBadRequest,
>>> }
>>> ...
>>> )
>>>
>>> Only here I don't like that I'm using global variables, rather than
>>> constants, and I don't like that I have to specify each error code directly
>>> (but then I'll have to do that in the documentation anyway).
>>>
>>> Is there a better way of handling this than one of these two methods?
>>> Otherwise I'd love to get feedback on the two methods that I've described.
>>>
>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/VzDfhN4GtIY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
