Enhancement: Add class and funcion name to ImproperlyConfiguredExceptions

[rafalkrupinski]

Summary

When you forget to add a type annotation in a route handler function, Litestar raises ImproperlyConfiguredException but neither the stack trace, nor the message shows which function or method is in error.

If the annotation were checked in @get decorators, the stack trace would let you find the line with the problem. If that's impossible, the exception should at least show function name, and the class in case of methods.

I volunteer to add function name in _validate_handler_function().

Basic Example

No response

Drawbacks and Impact

No response

Unresolved questions

No response

---

Note

While we are open for sponsoring on GitHub Sponsors and
OpenCollective, we also utilize Polar.sh to engage in pledge-based sponsorship.

Check out all issues funded or available for funding on our Polar.sh dashboard

• If you would like to see an issue prioritized, make a pledge towards it!
• We receive the pledge once the issue is completed & verified
• This, along with engagement in the community, helps us know which features are a priority to our users.

[euri10]

I definitely +1 this : I found that when switching from another framework, sometimes you make big refactors, forget some stuff and get hit by that and it's hard to find where you made the mistakes as you just changed too many things, this would definitly make the process smoother.
There are obviouly other cases for that, but this one comes to mind :)

[rafalkrupinski]

when switching from another framework

That's exactly where I'm coming from

[euri10]

I should have listed them, but there were other cases where this ImproperlyConfiguredException popped up in case of big refactors, and wasn't too useful because of the lack of more granular info. Would that be a good time to list where they're used and maybe investigate if providing more info would make sense ?
Anyways a goo 1st step would be this, thanks for raising it.

[provinzkraut]

Would that be a good time to list where they're used and maybe investigate if providing more info would make sense ?

Yeah, absolutely. I think we can generally improve a lot of our error messages with more details to make them more useful, but it's going to be a longer process I think. Incremental PRs are definitely welcome there! :)