Please see my comments to the question. Not quite clear.
If I guess the idea correctly, you need to keep debugging process when you have a failure of a certain operation like sending a e-mail and do it automatically (because otherwise you can always do it manually). Unfortunately, you did not share the application type.
So, I'll try to give you an idea based on a simple console application for now. If you can grasp it, you will be able to adopt it to different situations. If not, please respond — we can further discuss it.
I don't think you can restart the application exactly as you would do it manually using the debugger, without any manual operations at all. You can do different thing: make is the way is logically the same as restarting. Strictly speaking, this is valid only if you are not using any static fields/properties, otherwise repeated debugging may be not strictly the same as in the first run. Practically, you can ignore the problem and later re-test the functionality in "real" settings.
So, consider you have some console application which does it all. Let's assume it looks like this (simplified):
class Program {
void SendMail() {
smtpClient.Send(mail);
}
static void Main() {
SendMail();
}
}
You can modify it in this way:
class ResetException : System.ApplicationException {
internal ResetException(System caughtException) : base(null) {
InnerException = caughtException;
}
}
class Program {
void SendMail() {
try {
smtpClient.Send(mail);
} catch (System.Exception e) {
throw new ResetException(e);
}
}
static void ImplementMain() {
SendMain();
}
static void Main() {
while (true) {
try {
ImplementMain();
} catch(ResetException e) {
System.Exception exceptionToLog = e.InnerException;
Log(exceptionToLog);
}
}
}
}
Are you getting the idea? You can put any breakpoints, and, in case of failure, simply hit F5 to continue debugging without manual restarts, while being able to analyze the failures. Pay attention that the "application"
ImplementMain
is restarted only if the exception was thrown and caught only for specially chosen fragment(s) of code, otherwise the whole application will be terminated, but you can catch other exceptions, too. It's critically important that you never block the propagation of the exception, perhaps except the very top stack frame of the stack of each thread.
If this does not provide you with a technique you want, please respond; I'll gladly discuss it. With UI application the solution will be more complex, but the very general idea is pretty much the same.
—SA