• Exceptionally compliant frist (unregistered)

    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.

  • my name is missing (unregistered)

    So the exception is the rule?

  • RLB (unregistered)

    And sometimes, you just want policing by the exceptional application of a rubber hose.

  • Prime Mover (unregistered)

    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.

  • Ignorant Joe (unregistered)

    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#?

  • (nodebb)

    Code review. Invite the boss, and whoever has influence and motivation to enforce the standards.

    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.

  • Edd (unregistered)

    Wish there were a workaround for 'You're a character over the line limit and forgot to run the linter" errors

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    The developers are the standards enforcers and the standards enforcers are the developers.

    Sounds a lot like Boeing and the 737 MAX certification!

  • //NOSONAR (unregistered)

    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.

  • (nodebb)

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

    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. Modify the interface.
    2. Make the new exception a subclass of an existing exception.
    3. Throw an unchecked exception

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

  • (nodebb) in reply to //NOSONAR

    This rule is a good one - usually catching everything is a mistake and you should think more about it

    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.

  • Therac-25 (unregistered) in reply to Ignorant Joe

    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.

  • mushroom farm (unregistered) in reply to Exceptionally compliant frist

    I've suffered a lot from managers like you.

  • DanK (unregistered) in reply to Ignorant Joe

    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.

  • Blue Beard (unregistered)

    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!

  • David Mårtensson (unregistered) in reply to Ignorant Joe

    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.

  • masterX244 (unregistered) in reply to DanK

    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

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to Exceptionally compliant frist

    More responsibility? This is absolutely brillant code! Why hasn't he already been promoted to management?

  • Simon (unregistered)

    Exceptions are just "COMEFROM" statements and should of course be Considered Harmful.

  • mushroom farm (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    Judging by their original comment, I expect Exceptionally compliant frist already has.

  • (nodebb)

    If people are resisting "standards," then by definition they aren't agreed upon.

  • ZZartin (unregistered)

    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.

Leave a comment on “Exceptional Standards Compliance”

Log In or post as a guest

Replying to comment #:

« Return to Article