Caught exceptions reasonably report little or no diagnostic information when there is assumed to be no one ready to diagnose. However, the user's interface can be extended with diagnostic tools and a path into them provided so that user and developer can work together.
I consider two examples were a debugger remains available and the delivered code takes that into account.
I found tremendous advantage writing financial software by insisting that error and conflict free paths through the code were plenty enough to consider. The remainder, the situations that threw errors, were meaningless.
Should errors occur our programs would abandon a calculation and leave its field blank. Occasionally support was asked why a particular field was blank. If there were no domain related reason then the question would escalate to a developer.
A developer considered a blank field something to be given meaning. A shift-click retried the calculation and trapped into the debugger upon error. After a few minutes browsing domain objects, working in the context of the support call, and with domain expertise at hand, a useful behavior would be worked out and coded without leaving the support desk.
We supported this situated development with instant field patches that would also fold smoothly into our development pipeline.
Federated Wiki offers this advice when plugins fail to render and the user asks for help.
When things go wrong rendering a plugin the error is caught and a mysterious messaged displayed. This commit adds a help button to the message. Help opens a dialog with some hints and offers to retry the errant plugin without the error recovery so that the inspector/debugger can do its thing. github