-
Notifications
You must be signed in to change notification settings - Fork 43
Can't catch errors of path params #28
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
Comments
Due to the lack of a proper way to handle errors generated by the library i preferred going the default value route of handling bad values. I am still unsure what would be a good way to handle the exceptions, but just throwing the exceptions is unacceptable. Maybe a route module that has a function to generate the error, but then how do you differentiate the errors ? How do you make proper error codes ? How do you handle error payloads with the codes ? |
So I should do something like the following? @Path("{iii}")
data class MyParam(@PathParam("I'm int") val iii: Int?)
route("my") {
throws(
status = HttpStatusCode.BadRequest,
example = "bad request",
exClass = Throwable::class
) {
get<MyParam, String> { param ->
requireNotNull(param.iii)
respond("I received ${param.iii}")
}
}
} Okay... |
More like: val validParam = iii ?: error("iii: invalid value, must be an int")
... On a small scale it may seem easier to just throw a bad request but on bigger codebases, with a more complex error ecosystem you can't get away with only one handler. You want to generate error codes and payloads with relevant data so you can handle them properly in the front end without massive lookup tables that can break easily. For now the nullable approach guarantees that whatever we come up with won't break existing code when we do implement a proper handling system. |
Redirecting to #29 |
I've just understood that if I declare such a field as nullable, it will be shown as nullable in Swagger. So I need to add some extra text like "if you pass nullable or incorrect value, 400 will be returned". So it's not good working workaround... |
You can replace the primitive default values with a ParsingError throw in |
You could also create a processor like this to remove the nullable and throw your custom error: |
When I do http://localhost:8080/my/dassda , I want to see a bad request, but I get
I received 0
. Revision I use is be025c9. Is there a way to handle bad params?The text was updated successfully, but these errors were encountered: