- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I wouldn't fire the responsible developer but give him more responsibility - that way he might either suffer from his own tricks and/or find smart solutions to real problems.
Admin
So the exception is the rule?
Admin
And sometimes, you just want policing by the exceptional application of a rubber hose.
Admin
Code review. Invite the boss, and whoever has influence and motivation to enforce the standards.
Innocently ask: "I'm having difficulty getting my head round the reason for this construct. Can you explain why you're doing it like this?"
Then you just wait for him to explain exactly why. If he avoids it, keep pressing the question until he finally admits: "So I can squeeze my way around the standards without actually writing my code so as to adhere to them."
Job done.
Admin
Forgive my ignorance, but what is the harm in a blanket catch-all exception handler? Sometimes you have code where you don't care what exception was thrown, you just need to handle it. Maybe log it and move on. As a Java developer, maybe I'm just missing something innate to C#?
Admin
Right. Rather than admits he's trying to work around the standards, he'll say that the standards are impossible to comply with and he's just trying to get his job done. The boss will simply see two people that disagree and flip a coin.
I've seen it happen for the most egregious offences: exception swallowing, string concatenation for sql statements, roll-your-own encryption.
I once wrote a "password recovery tool" as a demonstration that we were encrypting rather then hashing passwords. Management gave it to the help desk as a tool and the responsible developer called the vendor to tell them that their encryption had been broken.
Admin
Wish there were a workaround for 'You're a character over the line limit and forgot to run the linter" errors
Admin
Sounds a lot like Boeing and the 737 MAX certification!
Admin
Code style and static analysis tools are fine as long as the rules are agreed to make sense, and treated as guidelines. It should be easy to mark an exception - and that exception should pass code review, but it shouldn't be unreasonably difficult to do so. This rule is a good one - usually catching everything is a mistake and you should think more about it - but sometimes (particularly when calling out to an external library) you do want to catch everything.
(This rule has probably been copy-pasted from Java, where checked exceptions mean it makes more sense. If you're calling unknown code in .Net, it really could throw anything and there's not really any way to know what the list could be.)
And code style rules should be set to allow for different people to have a different style, as long as it's all readable. Unless someone's really going off the deep end, differences in style are never an actual problem.
Admin
C# didn't implement checked exceptions because this often doesn't actually happen in reality. In Java, if a new version of a method needs to throw a new exception, the authors has the following options:
#1 is a pain for the caller because they have to modify and recompile the calling code. Since vendors hate support tickets, they avoid this one like the plague. #2 causes the caller to use existing handling code that may or may not be appropriate. Given that this is a really common pattern in real life, it means that even specific exceptions handler need to be a bit more generic than one might expect. #3 would require that the caller catch at least RuntimeException, if not Exception, which is what the coding standard is trying to avoid.
So, in reality, if your Java code lives for more than a few years, it probably will be expected to catch pretty much anything.
Admin
At best, medium good. Just last week, I was handed a production issue for code that uses RestSharp. It turns out that RestSharp doesn't throw exceptions from the Execute method - instead it updates the client object with any errors that occurred. This is why I'd much rather see exception handling as something the code reviewer handles rather than hoping that we can cover it with rules.
Admin
If there's an error like "Safety levels exceeded" and you catch it with "Turntable in X-Ray mode", a lot of assumptions are made, like menu interaction from the keyboard aborts an 8 second startup. Today if there's a database error, how don't you know your program is the one that took everything offline?
Unhandled exceptions just restart everything. Not that bad. Crash by design.
Handled exceptions assume a lot.
Operational errors are part of the design, just IO. They stop exceptions, like checking for nulls, but require more work.
Admin
I've suffered a lot from managers like you.
Admin
If you don't know what exception you caught, how can you be sure that you handled it?
If you catch an unexpected exception, the best thing you can do is go to safe state. Since in Java or C# that means crashing the application, you don't have to catch the exception at all. Ignoring unexpected exceptions will cause your program to misbehave and may cause headaches, data loss, or even death in extreme cases.
Admin
Some other methods used by our dear friends in Europe:
Buccaneering
Penal transportation
Gin riots
Walling off the poor
50 farmers to a room for cheap textile labor
Trial by combat
To end it, all the Americans did was lure them deep in the woods, and shoot their scouts.
Sounds like the start of a really fun production system!
Admin
Sure there are occasions where what happened is not important but for stable programs we mostly want to resolve any exceptions to the best of our ability, and if not, be able to report a more comprehensive error with context relevant extra data.
In the best of worlds we would avoid most exceptions but for framework methods that is not always possible.
Admin
Unless you want to "capture" as much context as possible ionto the log before crashing. Knowing where the unexpected Exception is from helps more than just a crash without any information on where it originated from
Admin
More responsibility? This is absolutely brillant code! Why hasn't he already been promoted to management?
Admin
Exceptions are just "COMEFROM" statements and should of course be Considered Harmful.
Admin
Judging by their original comment, I expect Exceptionally compliant frist already has.
Admin
If people are resisting "standards," then by definition they aren't agreed upon.
Admin
That's one of those nit picky rules that makes sense in a class room setting but often doesn't make sense in real world coding. Specific exceptions are nifty but most of the time you just want to catch the error display/log it and handle them from the perspective of the over all impact of that try catch failing. Catching specific exceptions adds no value to that most of the time as your program won't handle specific exceptions differently anyways.