Summary

Currently error handlers must return an ErrorResponse object with type:

type ErrorResponse = {
  statusCode: HttpStatusCode;
  error: string;
  message: string;
};

While building with the new Event Handler I had a number of ideas that I'd like us to experiment:

• Can we change the return type of error handlers to ErrorResponse | Response? This would help in case customers want to have full control over what's returned by an error handler, similar to what they can do in regular handlers
• For named error handlers only (i.e. notFound and methodNotAllowed ) we should consider making the statusCode field from ErrorResponse optional, since these method already have a default one
• Right now both error and message are required, can we update the type so that at least one can be omitted? this reduces repetition in case I care about only one
• Finally, can I throw any of the built-in error classes (i.e. NotFoundError) from an error handler? Right now if I do that, the Event Handler interprets it as a runtime error and falls back to the default error handler (502)

Why is this needed?

None of the ideas proposed above is required per se, especially if it doesn't make sense or complicates the overall API, but I'd like us to consider them as I think they'll make the API more ergonomic.

Which area does this relate to?

Event Handler

Solution

No response

Acknowledgment

• This request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.