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

📝 [Proposal]: genericParseType should return error type for error handling #3393

Open
3 tasks done
ksw2000 opened this issue Apr 6, 2025 · 0 comments
Open
3 tasks done

Comments

@ksw2000
Copy link
Member

ksw2000 commented Apr 6, 2025

Feature Proposal Description

When genericParseType encounters a parsing error and no default value is set, it silently sets the zero value without returning an error or panicking.

func TestGeneric(t *testing.T) {
    var v int8
    u := genericParseType("2000", v)
    fmt.Println(u)
}
> go test --run TestGeneric -v
=== RUN   TestGeneric
0
--- PASS: TestGeneric (0.00s)

In my opinion, the return value of genericParseType should include an error. Functions like Query, Params, and GetReqHeader use genericParseType, but there is no error handling when parsing unexpected values.

Alignment with Express API

None

HTTP RFC Standards Compliance

None

API Stability

None

Feature Examples

func genericParseType[V GenericType](str string, v V, defaultValue ...V) (V, error)
func GetReqHeader[V GenericType](c Ctx, key string, defaultValue ...V) (V, error)
func Params[V GenericType](c Ctx, key string, defaultValue ...V) (V, error)
func Query[V GenericType](c Ctx, key string, defaultValue ...V) (V, error)

// If `defaultValue` is not set and a parsing error occurs, an error should be returned.

Checklist:

  • I agree to follow Fiber's Code of Conduct.
  • I have searched for existing issues that describe my proposal before opening this one.
  • I understand that a proposal that does not meet these guidelines may be closed without explanation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant