Hacker News Reader

> 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.

> Your wrapper version with the fancy colors isn't better.

makes me look over my shoulder.

> 3 Inherit the environment in the process forks. Don't make me manually go in and pass things down.

I do think this one has saved me a number of times though; being explicit. I find people polluting the namespace somewhat often; and it's more of an "don't do that" not "shit everything's broken"

I'm thinking of some project I'm working on where you pass in parameters and environment variables and it completely utterly ignores it.

It took me a while to figure it out. To start up the web server it calls some thread "provider" which calls a thread managing library manager, which calls yet another thread managing library which then forks some threads. Of course documentation is non-existent on most of it.

Within this garbled mess their was literally no way to say "I want to debug this as well" by passing down an environment variable.

I had to fork the various dependencies to pass down that. It's not a matter of well documented thoughtful code, that's not the issue. It's spaghetti dreams of teenage imaginations; an infrastructure of sandcastles ravaged by the oceans of time.

sanely steps through code without getting lost in a library maze

I'm not completely sure what you mean here? Debugger not stepping into 3rd party code? The debugger cannot know what you consider to be a maze and what not: are you developing said library? Then you want that code. You want only your code? Then you'll have to tell the debugger which is yours. Example implementation is debugging C or C++ with Visual Studio which has regex-based 'do not step into'.

Get a useful stacktrace that's not just lines of framework wrapper garbage and then an elipses.

Isn't this essentially the same as previous point? You want a relevant stacktrace, i.e. without 'getting lost in a library maze' so you'd need to filter. Don't know if that is implemented somewhere. I personally haven't encountered much need for that though: stacktraces contain the origin of the call (shared library or for Python etc the module path) so glancing over it I skip the 3rd party bits automatically.

In Java and c# why have we been typing pseudo-URLs (com.google etc) all these years if they aren’t going to be used for anything?

Sometimes you can't attach a debugger at all! I've dealt with plenty of things that will do some strange kind of fork/exec magic and shed all the debug information in the process.

And other things that will only show some small useless snippets of the stack. You pass a bunch of parameters to tell it to show more, but then invariably you find the code is using a custom logger that's cutting the thing off or some part of a library resets all your settings or the forked processes don't inherit everything, it almost never just does what you tell it to, there's something else in there ignoring it.

I wish I could have the opportunity to even get to that problem half the time

Don't replace the default logging mechanism. Your wrapper version with the fancy colors isn't better.

Disagree pretty strongly with this one. Colors make changes in the data pop instantly. Colors are for humans. Logs are for humans. Use structured data if you need computers to read it. Send that data to ELK stack. Also color is very easy to strip with a regex.

Though colors should be a logformatter on the output side, a wrapper or subclass of the system logger can still be useful for collecting context data that the system logger can't collect on its own.

The complaint wasn't color. Take laravel circa 2012 or so. All errors were expressed as like 80k of minified HTML so if you got an error in a unit test you better have a browser nearby to see it.

Some other systems will try to be helpful and traverse the object and display it on the screen. I've seen some that don't understand self linking datastructures and just give you a stack exhaustion whenever dealing with an error involving one because they try to infinitely recurse. Others, trying to "fix" this problem that's been easily fixable since the 60s with pretty simple algorithms, will instead only show a depth of maybe 2 or 3 levels and then you need to do a bunch of tricks to get a useful object

Other will not give thread information so you just get mystery errors without any way to attribute them.

Others will race condition the log and give you a confusing mess of partial data mashed together.

And yet others will just fall back to some generic "an error occurred" with no further information whatsoever. Still others will think you have no interest in strings over some random amount divisible by ten, say 50 characters long and just truncate them with no way around it.

And some you are expecting a longjump or a trap or an interrupt but instead it gets intercepted for the pretty logging and thus your tooling didn't see it and the faults go undetected

Then there's the ones that don't respect the call stack limit you gave the command line or the verbosity setting or things like polluting the call stack with layers of the error handlers.

There's one where the default logger synced on write so if the system crashed I'd get the last message, but the fancy logger didn't so I'd just get a bunch of corruption. It was just great!

They're generally speaking terribly done and I routinely have to disable them. It's just a clown car.

You probably have only worked on gifted perfect projects by flawless programmers, and I congratulate you!

I've dealt with mostly confused incompetent people who think they are really clever and just destroy things

> Ability to connect a debugger that sanely steps through code without getting lost in a library maze

Depends on your environment? I use WinDbg and it does pretty well when symbols are loaded. User-Kernel jumps are still a bit of pita, but breakpoints work

I like how you pull out the best debugger ever made out of your back pocket. Yes, windbg deserves shrines and holidays. After switching away from fulltime windows dev about 13 years ago, it's one of my fondest memories of how amazing windows can actually be.