Rethrown exceptions overwrite original stack trace and complicate debugging

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Cause any of a number of possible exceptions such as an authentication
exception.
2. This exception is caught and rethrown within the GData api.
3. It's then no longer possible to determine the true source of the error

What is the expected output? What do you see instead?
The stack trace should point to the originating location, not the rethrown
location.

What version of the product are you using? On what operating system?
This is specific to any .NET version.

Please provide any additional information below.
A quick web search for instance provides
http://www.tkachenko.com/blog/archives/000352.html
explaining the java vs. .NET difference causing the problem.

The Solution is fairly simple; All instances of 'throw [ex];' should be
either wrapped as 'throw new Exception("some message",[ex]);' or be
rethrown correctly as 'throw;' (without the [ex]).  It's an unfortunate
design flaw in C# which allows this to occur so easily at all.

Consequences of rethrowing as now are increased debugging difficulty. 
Since the Google Calendar API for .NET makes significant use of various
encapsulating techniques (such as factories and inheritance), it can get
quite difficult to determine the original source of the exception.  It's
(most probably) never a problem in a deployed application (i.e. when not
debugging), limiting the impact.

Original issue reported on code.google.com by eamon.nerbonne on 14 Nov 2007 at 2:12

[GoogleCodeExporter]

Good catch. There are 3 cases where this might cause a problem in debugging, 
all in gauthrequest.cs. Will fix for 
the next release (minor change). 

Original comment by fman...@gmail.com on 15 Nov 2007 at 10:35

• Changed state: Accepted

[GoogleCodeExporter]

fixed with release 1.1.2

Original comment by fman...@gmail.com on 15 Nov 2007 at 5:52

• Changed state: Fixed