Hardcoding statusCode is Response annotation

[SerVB]

I don't find any Int constants, so currently I suppose hardcoding like 404 is required.

And if somebody reworks Response annotation so it accepts HttpStatusCode instead of Int, it will be a duplicated description (Response.description and Response.statusCode.description). There is another solution I see: leave only a single parameter in the Response of HttpStatusCode type but it's not pretty because of the class name. Actually, I've planed to open a PR with the first solution but now I don't know what's more elegant in that situation.

It's a related to #24 because it's about description too.

[Wicpar]

You cannot have normal classes in Annotations class parameters, i would have done that if it was possible...
Only primitives, enums and other annotation classes are allowed.

HttpStatusCode is a data class from Ktor, you can do this:

HttpStatusCode.BadRequest.copy(description = "Description")

and even

HttpStatusCode.BadRequest.description("Description")

As for making the @Response annotation work for the throw handler it is a possibility, but the current usage we have reuses the same response class for all different errors as it is the same model.
Having to rewrite a different class for each kind of exception would create too much bulk.

We are going away from the current system with #10
We will clarify this usage with that rework, where you could do something like:

post("{id}")
@Throws(BadRequestException::class)
@Description("The description")
{ 
    @Body request: RequestBodyClass, 
    @PathParam("id") idParam: Int ->
    return@post  SomeResponseObject()
// OR
    return@post  ResponseWithCode(SomeResponseObject(), HttpStatusCode.BadRequest)
}

The Throws is the kotlin annotation, and it will look if there is a handler for that specific type registered in the path or globally, or directly on the annotation class.

The ResponseWithCode will be a special class annotated with a response transformer handler, which allows you to modify modularly the response OpenAPI definition, and even the Serialization behavior (like RespondXML(ResponseObject()))

You will be able to create new annotations in a modular manner.

Thus i am closing this issue, as it has a usable workaround, and will elegantly be reworked with #10.