Contrary to the opinion that throwing exceptions from Controller handler methods is bad, I do recommend to do so. The reasons are following:
It eliminates a lot of boilerplate code. Almost all try-catches in controllers are the same and are frequently copy-pasted from one place to another. It increases code maintenance burden and coupling between controllers and exception hierarchy.
There are other ways to handle exceptions correctly. Best solution is to have a global exception handler, which translates specific types of exceptions to HTTP response codes. E.g. when your database query or remote call fails with timeout, you can translate it to HTTP 503. When your repository throws ObjectNotFoundException, you can return HTTP 404. When validation fails, respond with HTTP 400. You can also have controller-specific handlers in few specific cases (vary rare situtation).
That said, it does not mean, that you should have "throws Exception" in method signature. In layered architecture objects in higher layers like controllers cannot expect low-level exceptions (e.g. from JDBC driver), because it would violate encapsulation. There should be separate exception hierarchy per layer, which has semantics specific for that layer, and there should be exception translation (normally done by wrapping). For example, ConstraintViolationException in Repository may result in InvalidServiceRequestException in Service and translated to HTTP 400 by exception handler.