A stack trace is usually not a vulnerability in itself. However, it can leak some information about the design of the software, which may be helpful to the attacker (e.g., revealing database versions, table names, code filenames, and so on). Therefore, usually it is not a good idea to reveal the stack trace.
The standard way of dealing with this is: turn off stack traces on production servers. You can turn on stack traces on debugging builds that are not exposed to the outside world, to help you debug crashes, but when you move it into production, turn off stack traces.
The web2py web framework has an even more elegant way of dealing with this issue. web2py never reveals stack traces to visitors. Instead, if an uncaught exception occurs, web2py constructs a new "ticket", reveals a ticket number to the visitor, and saves the details of the error (e.g., stack trace, etc.) associated with that ticket in an internal database. Ordinary visitors cannot see the details of the ticket, but an administrator can. An administrator can look at the list of all tickets. In addition, given a ticket number, the administrator can look up its details of that ticket and see, e.g., the stack trace. From a security perspective, this is a great approach.
(Incidentally, web2py is an elegant framework that has put a lot of thought into making security on by default and easy for developers. web2py tries to eliminate security pitfalls and make your service secure by default, to the extent that it can. If you're building a web service that needs to be secure, take a look at web2py!)