> Get a useful stacktrace that's not just lines of framework wrapper garbage and then an elipses. This is the biggest pet peeve of mine. Over the years I've sp

> Get a useful stacktrace that's not just lines of framework wrapper garbage and then an elipses. This is the biggest pet peeve of mine. Over the years I've spent too much time ensuring I can get a stack trace *WITH* line numbers. A stack trace without line numbers makes support much more difficult. For .NET why I need to generate and include .PDB files just to get line numbers I dunno. I've never ever used a .PDB for anything but stack trace line numbers. I'd bet that I'm not alone in this. Why the runtime could include them in the DLL (ok driven by a switch) I don't know. And for JS those .MAP files can turn out to be larger than the original source files. Which is a bit mind boggling. And don't get me started on .ts -> js -> bundled to get the map files right. And the JS client libraries to handle unexpected exception capture and logging. And the server side parsing of the client side error and map files to get back to an original error line number in a .TS file. It's downright shameful that the most assistance a runtime can provide is a stack trace without line numbers.