-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Proper handling of library generated errors #29
Comments
I am open to suggestions. The basic idea would be like this: @FallbackHandler(DefaultExceptionHandlerObject::class)
class KtorOpenAPIGenException(val errors: List<KtorOpenAPIGenError>): Exception("Relevant human readable version")
data class KtorOpenAPIGenError(val origin: KClass<*>, val what: String, val why: String, val where: String)
// example
KtorOpenAPIGenError(PrimitiveParser::class, "Could not parse parameter", "Bad format, should be an int", "theParameterName") Ideally there would be hints as to what the value should be beyond just the type, like if it is annotated by |
In a similar vein, how does one handle parsing requests types. Previously I would assign and type cast the incoming request in the body of route that would allow me to handle parsing issues e.g.
However this now appears to be out of my control, any suggestions on how I could handle the parsing of requests? |
regarding the above 👆 Ignore me, i had overlooked your examples, for the benefit of others though here was how to capture potential parsing of request types...
Happy to help contribute on this project as its very useful, perhaps I can help with the docs? |
Any help is welcome, especially with the docs :) |
Creating this because of #28
Currently there is no system to handle errors that occurred during runtime with this library. Instead i opted to use default values when parsing fails as it has best risk/effort ratio of the low effort options.
But now comes the time to implement it properly.
What it should do:
The text was updated successfully, but these errors were encountered: