Passing Exception Information
In the bad old days, when an application threw an exception, we frequently extracted the system-generated message and put it on the screen for the user to read. Often it included information that we'd prefer not to share with the outside world (table names and details of the connection string, for instance).
A better practice is to generate an application-specific message that reveals just what you want. And, unlike most system messages that describe what's wrong, your message could tell the user something useful: what to do to solve the problem. A unique message will also help you identify where things have gone wrong in your application. The right answer is to create your own Exception object with a unique message:
Try
...code...
Catch Ex As Exception
Throw New Exception("Something has gone horribly wrong")
End Try
However, when you're debugging, the information you need to prevent the exception from happening again is in the original exception object.
As some readers pointed out to me in comments to an earlier tip, the right answer is to pass the original exception as the second parameter to the Exception object's constructor. Enhancing my earlier code, the result looks like this:
Try
...code...
Catch Ex As Exception
Throw New Exception("Something has gone horribly wrong", Ex)
End Try
The Exception object you pass as the second parameter will show up in the InnerException property of the Exception object you're creating.
Posted by Peter Vogel on 11/13/2014