This question already has an answer here:
It is a known fact that exposing the exception information to the end user provides security risks since an adversary can user that to figure out how things work internally and attack it. But what about a web service, where that information might be relevant to the developers that consume the API?
On one hand exposing full stacktrace and even the message is risky since it might contain some database information e.g. on the other hand if something goes wrong and the server just says 500 "sorry", then developers would be frustrated. I guess really the proper way is to handle all exceptions you know of in a secure manner, i.e. catch business/validation exceptions and return it back with special error codes and messages (no stacktrace) and for all unknown still make 500 "sorry".
But I would like to here what are the common ways of doing it and which approach should be taken from security point of view.