I've never seen any API letting the client hanging in a case of an error.
Unless you have a very specific case where this makes sense¹ This simply doesn't make sense, and such behavior would only result in a practically unusable API:
This would slow the development of the client applications. Unless I read very, very carefully the documentation (and the documentation is excellent), I'll make mistakes which would result in timeouts, and thus slow development.
This would also make the client apps slow if they cause exceptions when used by an end user.
So no, don't do that.
What you should do is to handle the error gracefully. This means sending a response containing:
A specific HTTP code, like 404, 403, 500, etc.
The detail explaining what happened. Usually, this shouldn't be the exception itself, since it may contain sensitive information and you may want to provide something more understandable to your users.
Eventually the internal code. This may help when providing support. “I tried to access the list of products and got the error 7016.” is shorter to tell to the support than “I tried to access the list of products and got the error ‘The category is missing in the request. When querying for the list of products, the category should be provided.’”.
Eventually the link to the web page of your website which contains additional documentation, examples and workarounds.
"error": "The category is missing in the request. When querying for the list of products
, the category should be provided.",
The http://api.example.com/docs/errors/7016 page explains further how to avoid this error, i.e. what GET or POST parameter should be used in the request to specify the identifier of the category.
¹ I can imagine two cases: a super-secure API which needs to prevent its users from trying to break it and an API which wants to prevent DDOS. In the first case, it looks like a weak way to protect anything. In the second case, hanging without answering won't prevent the client from sending other requests meanwhile.