Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to add an error response override #7

Open
Gowiem opened this issue Dec 30, 2017 · 2 comments
Open

Add ability to add an error response override #7

Gowiem opened this issue Dec 30, 2017 · 2 comments

Comments

@Gowiem
Copy link
Contributor

Gowiem commented Dec 30, 2017

The current error response from email-service is to include the error message in a json payload under the key error. This is useful for development, but for more advanced purposes it would be ideal to allow for customization of this error response. Specifically, the company I am working for has standardized an error response from our APIs that I'd like our running version of email-service to conform to.

I'm going to fork and put together a working example, but want to raise this issue so I can get feedback if there is a particular way you folks would like this done.

Thanks for the great service! Will report back with a PR within the next week or so.

@gimenete
Copy link
Contributor

gimenete commented Jan 2, 2018

Can you share an example of that standardized error response?

@Gowiem
Copy link
Contributor Author

Gowiem commented Jan 3, 2018

Hey @gimenete, yeah sure:

export interface IApiError {
  name: string;
  status_code: number;
  error_message: string;
  dev_message?: string;
  validation?: { source: string, keys: any[] };
}

One library which does error handling well is Celebrate. They throw all errors and then provide a function (Celebrate.errors()) which adds their error handler. If the developer doesn't want their error handler than they don't add that as middleware and add their own custom error middleware themselves. I think that provides the best functionality for end users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants