there are guidelines for managing exceptions. creating, throw, catching, finalizing, etc. I would recommend reading up on these concepts so you know how best to handle this. exception handling is a language egnostic concept, so articles may not relate directly to .net, but java, php, ruby, etc. the ideas are the same.
with .net if you catch an exception to throw another then make sure you pass the original exception to the new excpetion. this way the stack trace will point to the original issue.
Code:
try
{
}
catch (ASpecificException e)
{
throw new MyException(anything I might need for my exception, e);
}
this way e will be passed to the inner exception property of the Exception base class.
you'll also note that I catch ASpecificException, not Exception. you should only catch errors you expect. the cases for catching all errors is very rare, and the GUI there is definitely not a need to catch generic exceptions.
I have found the best way to test code is through unit testing and unit testing frameworks like nunit or mbunit. this allows me to run 100's of tests in seconds confirming that my code is working properly.
combined with the concepts of single responsibility and dependency inversion I can test each object in isolation making sure the objects behave properly. then when i tie construct my object graph I know everything is working. by the time I run manual tests against the GUI I am confident all the logic and data access is working properly.
Jason Meckley
Programmer
Specialty Bakers, Inc.