Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Another possible extension of that design is using error types for HTTP codes. Something like:

  type HTTPError struct {
          Err  error
          Code int
  }
And then, with a couple of wrappers like this:

  func errorNotFound(err error) (wrapped error) {
          return &HTTPError{
                  Err:  err,
                  Code: http.StatusNotFound,
          }
  }
you could do something like this:

  return errorNotFound(err)
or this:

  return errorInternal(err) // 500 Internal Server Error


I usually create an abstraction like this in an API to require all returned errors to come with some sort of machine readable code. You either have to classify this response with an existing code in the list or add a new one. That list then gets generated as part of the documentation so consumers are getting possible error states straight from the code (without having to look at said code).


I do similar: I create a `handleError` function that deals with the error (logs it, reports it, redirects to the appropriate page), and call that in a return statement.

It's like 5 minute's work to code up, and I get to set whatever logging destination and redirect logic works best for my project.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: