Restarting message loop with new form after exception

  • Thread starter Thread starter Scott Gifford
  • Start date Start date
S

Scott Gifford

Hello,

In my Main() method in Program.cs, I have an exception handler around
my Application.Run(). If I catch an exception, I would like to bring
up a dialog box asking the user if they would like to send an error
report.

In my first attempt, I created the form for the dialog box, then tried
to restart the message loop with another call to Application.Run().
Unfortunately, this call to Appliction.Run() immediately throws an
exception. The documentation says that this will happen if I try to
start a message loop on a thread that is already running a message
loop, and Application.Run() seems to think the message loop is still
running. Perhaps this is because it was exited abnormally via an
exception.

In my second attempt, I starting a new thread, and called
Application.Run() from there. This works, but adds a lot of clutter
to an otherwise straightforward piece of code, and seems a bit kludgey
besides.

Is there a better way to do this?

Thanks!

----Scott.
 
It seems to me that if you end up in a handler back around run, then it's
uncaught elsewhere and state is pretty much undefined at that point. If it
were me, I'd actually let the process die and relaunch - just do a
Process.Create in the handler and re-launch. Anything else is asking for
trouble.

-Chris
 
Chris Tacke said:
It seems to me that if you end up in a handler back around run, then
it's uncaught elsewhere and state is pretty much undefined at that
point. If it were me, I'd actually let the process die and relaunch -
just do a Process.Create in the handler and re-launch. Anything else
is asking for trouble.
Click to expand...

Thanks, Chris. You're right, the application state is undefined, but
the log upload window ignores the previous state, and just uses things
that are under its control: objects it creates or a few static
properties. Since it's running in a new message loop I don't see much
risk of the corrupted state from the previous window causing problems,
but perhaps there's something I'm missing.

I have a few pieces of state that come from the application that I'd
like to pass along to the log upload window, which makes using
CreateProcess a bit tricky; I would have to put them all on the
command line, taking care to escape everything properly so it doesn't
launch something I don't expect, then unescape them when parsing the
command line. All do-able, but a bit of a hassle, and somewhat
error-prone, with possible security risks if I get it wrong.

-----Scott.
 
I'd be inclined to dump out a "state file" instead of using the command
line. I'm certain you could get another message pump running - it might
require some hacky waiting for the current pump thread to die or just using
something like OpenNETCF's Application2.Run to create your own pump (because
it doesn't check for multiple pumps). Still, my gut tells me that that
second pump is going to lead to some weird headache down the road and it
will manifest itself in some weird way that sucks up a week of beating your
head on the desk. I'd just dump whatever state you want saved to a file,
re-aluch, and load it back up. There are lots of ways to do that - a
personal favorite is the AppSettings stuff we added to the SDF in the last
version, but I'm a bit biased. I did, however, write it for almost this
exact type of use - for persisting application state across runs.

-Chris
 
Chris Tacke said:
I'd be inclined to dump out a "state file" instead of using the
command line.
Click to expand...

Yeah, that's a good idea, I should be able to do that from the
exception handler without needing a new message loop.
I'm certain you could get another message pump running - it might
require some hacky waiting for the current pump thread to die or
just using something like OpenNETCF's Application2.Run to create
your own pump (because it doesn't check for multiple pumps).
Click to expand...

I just created a new thread and ran the message pump there, then had
the first thread Join the new thread. It was straightforward enough,
but yeah, a little hacky.
Still, my gut tells me that that second pump is going to lead to
some weird headache down the road and it will manifest itself in
some weird way that sucks up a week of beating your head on the
desk.
Click to expand...

:-) Thanks, I'm sure that by now your gut must be well-tuned to these
sorts of things.

---Scott.
 
I always find this a bit of a kludge anway, wrapping the message pump with a
try catch statement. The proper way to do it is to let the app domain handle
the exception by registering AppDomain.UnhandledException if you are using CF
2 or later.
 
Back
Top