"throw ex;" truncates StackTrace

Question

I searched the forum to see if anyone had inquiried about this before but didn't find. So here's a question.
Is there a reason for re-throwing many of the exceptions caught through-out the code ? I see a lot of this:

catch (WhateverException ex)
{
      SomeCleanupCode();
      throw ex;
}

And, since the above idiom effectively truncates the stack trace right at the throw statement, I thought it would be more logic to have something like:

catch (WhateverException)
{
      SomeCleanupCode();
      throw; //just bubblet the exception up
}

OR

catch (WhateverException ex)
{
      SomeCleanupCode();
      throw new MoreMeaningfulException("Message", ex);
}

OR even (ignoring the original exception):

catch (WhateverException ex)
{
      SomeCleanupCode();
      throw new MoreMeaningfulException("Message");
}

Well, it has not been a big deal for me now, and I hope it'll never be, but I though I would ask this to understand the code better.

Thanks for an excellent piece of software!!

- Sergio Pereira

Answer 1

Sergio, many thanks for pointing this out. We ported edtFTPnet from edtFTPj, and the "throw ex;" idiom doesn't truncate the stack trace in Java. We didn't realise that it did in C#.

We are going thru all our code and amending it to simply "throw;"

Again, thanks for letting us know.

I searched the forum to see if anyone had inquiried about this before but didn't find. So here's a question.
Is there a reason for re-throwing many of the exceptions caught through-out the code ? I see a lot of this:

catch (WhateverException ex)
{
      SomeCleanupCode();
      throw ex;
}

And, since the above idiom effectively truncates the stack trace right at the throw statement, I thought it would be more logic to have something like:

catch (WhateverException)
{
      SomeCleanupCode();
      throw; //just bubblet the exception up
}

Answer 2

Hi, Bruce. Thanks for the reply.
Just to let you know how I changed some of the code myself. I did replace almos all the "throw ex" with a plain "throw", only in the section below from FTPControlSocket.cs I chose to use an InnerException construct because the logic of the methos was slightly different than the rest.

internal virtual void Logout()
{
        //...snip ...

        if (ex != null)
        throw new SystemException("Error while freeing up resources.", ex);
}

Another idea you might consider for later versions of the component is to make some of the classes implement IDisposable so the users don't need to remember to call stuff like Quit() or similar. C# programmers are used to have resource-bearing objects implementing this interface, so they can wrap the objects in using(){ } blocks.
Just a thought. Thanks for the clarification regarding the port.