Like I mentioned, just because you dislike something, doesn’t mean it’s actually unfavourable, or that other people shouldn’t see it, and that holds true a lot of the times, unless you’ve sort of geared yourself such that what you dislike is also something unfavourable. But even so, you can’t assume that other people would be or do the same.
And yeah, they’re functionally the same, but the intent is different. The point here is that votes have intentions behind it, and what we’re telling you is that it shouldn’t be a self-centric intent.
For your last question, I actually don’t really have a good answer for you. I’ve seen many people react in similarly clueless ways in order to rile others up. I’ve also seen too many who can’t look at things pass their own lenses, can’t properly put themselves in someone else’s shoes (despite claiming they do, but what actually happens is that they’ve set up a convenient strawman of the person and put themselves in that instead), and can’t think for the sake of others, and how this shows through how they use social platforms. So I guess I’m being wary.
It seems like the author thought stack traces are underrated because people don’t like exceptions and don’t always
throw. It seems like they don’t understand why people don’t like exceptions, and think that stack traces should be there for every case where the author thinks should be an exception, and ties the desire to avoid exceptions to some strawman use case — a nice looking output — and called it “modern error handling”.Error / exception handling is separate from stack traces. You don’t need to have an exception to have a stack trace, and stack traces aren’t just used for exceptions.
They also seem to not understand why people make do without stack traces in a microservice architecture. That’s simply not true. First off, you can still get stack traces of individual services. And secondly, if you build your services to accept, eg, something like a tracing ID, and print it along your logs, you essentially have a stack traces across services. In a web service, you can track the work done by all your systems for a single request from the client.
Now, onto why exceptions are somewhat disliked. Let’s just get the simple stuff out of the way: they’re generally bad for performance; they’re invisible to the method caller until they run into the problem, meaning you can’t ever ship updates that you’re confident won’t fall over disgracefully; try-catch hell, etc.
For a slightly more philosophical answer, why aren’t your exceptions just cases you need to handle? The try-catch pattern essentially builds up a separate channel of logic where your program needs to operate in but is expressed or recorded in very fragmented ways, forcing devs to have to pop open every function to look at why something is thrown, and hope that somewhere down the stack, no new exceptions are being thrown and not handled. The logic behind exceptions becomes second-class citizens that programmers can easily forget, instead of being front and centre. Can’t divide by 0? Tell me instead of setting me on a separate handling path. Why should I try-catch every single method call, or even property access? Don’t wait for the user to hit the call and just tell me that something is supposed to be impossible, or if I should handle the case where it doesn’t hold any values, right as I compile (dynamic languages can’t really do that).