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??
I think that was the right approach, then again didn’t you have through a pull request or at least a code review? Knowing that would give raise to so many “errors” you should have had some sort of communication beforehand.
I don’t blame you, more the workflow and ironically the manager
Oh that was like years ago! Probably SVN, we on-boarded Git a little while after.
No pull requests, you just manually merged back then. It’s definitely a workflow improvement we adopted later and we as a company and as an industry have gotten better.
lol, the thing was just that my manager asked me what I did and I told him. Him getting another dev to “fact-check” me after is what bothered me a bit. I am usually the type of look into issues rather than brush them off and I am the first to confess to a screw up. Which is why I was irked.
This is a massive assumption from the story that was provided. We don’t know that they didn’t discuss with the team and an explanation of “I added a log to errors that were already happening” shouldn’t result in lack of trust from the manager.
Reactive managers like that are a big problem in the industry.
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
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??
oh yeah I just logged and rethrew, so it shouldn’t have had any behavior change, but I could have broken something I make mistakes all the time.
The errors we were seeing in logs were like logic or application errors that we just didn’t see before. My changes really shouldn’t have caused.
I think that was the right approach, then again didn’t you have through a pull request or at least a code review? Knowing that would give raise to so many “errors” you should have had some sort of communication beforehand.
I don’t blame you, more the workflow and ironically the manager
Oh that was like years ago! Probably SVN, we on-boarded Git a little while after.
No pull requests, you just manually merged back then. It’s definitely a workflow improvement we adopted later and we as a company and as an industry have gotten better.
lol, the thing was just that my manager asked me what I did and I told him. Him getting another dev to “fact-check” me after is what bothered me a bit. I am usually the type of look into issues rather than brush them off and I am the first to confess to a screw up. Which is why I was irked.
A manager that can’t read a simple try catch commit? Why am I surprised.
deleted by creator
This is a massive assumption from the story that was provided. We don’t know that they didn’t discuss with the team and an explanation of “I added a log to errors that were already happening” shouldn’t result in lack of trust from the manager.
Reactive managers like that are a big problem in the industry.
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