Proposal: How about allowing ServiceError to wrap error?

[ikawaha]

Motivation

The motivation for this proposal comes from the error handling in the middleware.

I tried to create a middleware that only logs specific errors, but I had to parse the error message to distinguish whether the "internal_server_error" was a DB error or some other unexpected error, and so on.

I am thinking that if the original error is embedded in ServiceError, it would be possible to distinguish the error by error type without having to parse the error message.

TL;DR;

• A field is added to ServiceError to hold the error and the Unwrap interface is implemented.
• The generated helper functions (MakeXXXX) wraps the error.
• The original error is embedded or attached in ServiceError, making it easier to handle errors with errors.Is() and errors.As().

PoC

• PoC 1: Add a field to the ServiceError structure to hold the error
  • PoC 1: ServiceError wraps error #3059
• PoC 2: Keep existing MakeXXXXX and also generate MakeXXXWrapped that can wrap errors
  • PoC 2: ServiceError wraps error #3061

[ikawaha]

Thanks a lot for all the advice.

I have written another PoC to see if I could handle this by adding new helper functions without modifying the core Goa structures. This method does not affect existing user code.

#3061

Please tell me what you think.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.