More flexible ErrorHandler function to plugin in oapi validator middleware #27
Description
Introduction
Currently, it is possible to pass in custom error handlers to be able to handle errors in a customised way as needed in case middleware validator fails, which is nice.
nethttp-middleware/oapi_validate.go
Line 20 in 5324ea6
What is the problem
It would have been nicer if the error handler function also had an option of receive the http request object as to construct more schematic errors and respond with that. This may need the request details and context.
I understand that this can be more specific to the consumer of the library (which is me right now!), but I was wondering if this flexibility can be added without breaking existing users.
Proposed Solution of the problem
The solution that I am trying to propose here is just a starting idea(and can have cons) and need not be exactly like this. This can require discussion in the community to be able to come with a different one or build on this.
One option would be to introduce an altogether new error handler with config function that accepts an handler config which is illustrated in the code below:
( Please excuse the namings, i just want to propose the idea )
// Options to customize request validation, openapi3filter specified options will be passed through.
type Options struct {
Options openapi3filter.Options
// INTRODUCE an ErrorHandler with config.
ErrorHandlerWithConfig ErrorHandlerWithConfig
ErrorHandler ErrorHandler
MultiErrorHandler MultiErrorHandler
// SilenceServersWarning allows silencing a warning for https://github.com/deepmap/oapi-codegen/issues/882 that reports when an OpenAPI spec has `spec.Servers != nil`
SilenceServersWarning bool
}
// INTRODUCE an ErrorHandlerConfig struct.
type ErrorHandlerConfig struct {
w http.ResponseWriter
r http.Request
message string
statusCode int
... // extensible to other probable fields
}
// INTRODUCE a new function error handler function.
type ErrorHandlerWithConfig func(config ErrorHandlerConfig)We can skip executingthe current error hander and execute ErrorHandlerWithConfig if it is not empty otherwise fallback to using the current one if provided.