0

At the company where I work, the below pattern occurs frequently:

public void MethodThatCouldThrow() 
{
    try 
    {
        // do something which could lead to an exception being thrown
        ...
    }
    catch (Exception ex)
    {
         throw;
    }
}

What is the benefit to do doing a naked throw; like this?

From my understanding, there is no benefit: The stack trace does not change, so it's like the above try catch block wasn't even there. No additional information gets added to the error.

I understand that if you are doing some additional work inside the catch block, then this might make sense, but my question is specifically about the case where throw; is the only thing inside the catch block.

emiliojazzar
  • 3
  • 1
  • 1
  • 2
    I've closed this as a dupe, though it's not really your answer. The code above is fairly pointless in terms of functionality, but it might get past some code analysis tools. Either way, you need to talk to your team about why this is done as this is an opinion-based technique. – DavidG May 10 '23 at 10:57
  • 2
    There's no point in doing it if there's nothing inside the `catch` other than the `throw;`. – ProgrammingLlama May 10 '23 at 10:57
  • 3
    I've often seen this pattern when a developer wants to place a breakpoint inside the `catch`, not knowing how to use exception settings in the debugger. I wish I could say this little bit of unnecessary code doesn't make it into the codebase, but it does. – David May 10 '23 at 11:00
  • 1
    The only reason I could imagine is that somewone used it during debugging just to put a breakpoint on the `throw;` and then checked it in by accident. – Klaus Gütter May 10 '23 at 11:01
  • 1
    It raises the LoC counter ;o) - heard too much "look how much LoC we have" as if it is an indicator for quality – Sir Rufo May 10 '23 at 11:15

0 Answers0