I remember when I was working with .NET and I saw some web service code and I saw there was no try catches. They didn't have a global catch in the asax either or anything. I just wrapped each call into a try catch and log.
I got the same treatment where my manager wanted to know what happened with the increase in errors. I told him what I did. My manager got another developer to go through my commits regardless. I was a bit upset at the lack of trust.
I mean, that 'could' be a straight up wrong thing to do if some of the calls were expecting errors to be able to escape. Yea, it'd be super weird and I don't know if .NET would marshall them anywhere, but in some systems, that sort of, "obvious" fix could break shit. Sure, it'd be something doing something weird and kinda' dumb, but ... don't we see "weird and dumb" all the time??
they shouldn't have to do that. the commit log tells the manager who to go ask.
and since the developer did that to be a big swinging dick instead of bringing it up to the team in a meeting as a problem to address together the manager didn't trust them.
makes sense to people that have to manage other humans.
I joined a team years ago where everyone would catch exceptions then throw a different exception in the catch, swallowing the original. Sometimes these were nested many layers. Troubleshooting was a nightmare.
I spent a week deleting all of them and told everybody that "try" was now a forbidden word outside of entry points.
I remember doing that as a junior because everyone in our codebase did it!
My new team lead came in and asked me why. I said it's to reformat it due to the layer it was in. He said "...and what did you really accomplish with that?" All we did was bury our real error really well. It made me think about these things and to question convention more
Changing the error level in the build config without telling everyone and then making a hyperbolic passive aggressive comic when the senior admonishes you for doing so ?
I'm gonna guess 1 YoE, second job out of college. Enough experience to know what they're doing, but not enough to know when to do it.
It's the delusion stage, when you think companies are places where you do professional work. Then you learn no one cares about properly doing your job. In fact, they'd rather you do not.
Ah, that hits close to home. I have spent a lot of time and energy to get my direct bosses onboard with following best practices and doing things right from the start. To their credit, they got onboard with it and are pushing that message themselves now. Of course, the board doesn't care about that and just jams random projects with strict deadlines without any thoughts given to the IT aspects of it up our asses, but our head of IT has apparently grown a spine and started pushing back, with some moderate success.
The MO of my company has for years been: do a POC and then as soon as it works, push that POC in production. I'm still cleaning up the mess of idiotic shit like that from 15 years ago.
No, we cannot just put every random library on the server. Please stick to the stable ones the team picked, not random ones you just heard about and wanted to try in production.
"My project" doesn't exist in any team. It's everyone's project. A manager needs to have a long conversation with Pink Pants.
If you build your project at anything but highest error level, clang -Wall etc., you're letting errors in, relying at best on coincidence to work the way you think it does.