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

Make huma play well with custom error types returned from handlers #482

Open
betaprior opened this issue Jun 15, 2024 · 0 comments · May be fixed by #504
Open

Make huma play well with custom error types returned from handlers #482

betaprior opened this issue Jun 15, 2024 · 0 comments · May be fixed by #504

Comments

@betaprior
Copy link

betaprior commented Jun 15, 2024

My use case is using huma with an existing backend that makes heavy use of custom error types. In echo, it was possible to write a custom error handler that uses a types switch on the custom errors. Unfortunately, with huma these errors are converted using NewError(http.StatusInternalServerError, err.Error()).

Thus, even though the docs suggest overriding huma.NewError for custom logic, it is not an ideal solution because the original error type is lost and only the string representation remains. It is possible to perform custom logic by parsing the string, but it's a far cry from a type switch.

This is despite the fact that signature of huma.NewError accepts any number or errors as arguments, so it would be perfectly feasible for a custom implementation to do arbitrary processing if these errors were actually made available.

But even more confusingly, parsing the error code string in custom NewError also doesn't seem to have the desired effect!

huma.NewError = func(status int, msg string, errs ...error) huma.StatusError {
    if strings.HasPrefix(msg, "code=404") {                                   
        status = http.StatusNotFound                                          
    }                                                                         
    return DefaultErrorHandler(status, msg, errs...)                          
}                 

This returns an ErrorModel JSON with status set to 404 but the response status is still 500 🫤

I can work around this by forgoing overloading NewError and instead using a transformer function that explicitly calls context.SetStatus(code), but this seems a bit counter-intuitive.

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

Successfully merging a pull request may close this issue.

1 participant