I’m guessing a few of you may have seen this dialog before…

This is what you get when there is an unhandled exception in your .NET code
that’s running in ArcMap. And it’s not exactly handy for an end user – what does
a stack trace mean to them? Not much. So the question becomes – can we replace
this dialog with our own, have it inform the user gracefully that an error has
occured, all the while logging the stack trace and other useful information for
the developers/administrators.

I should stop here and note that what I’m trying to catch are truly unhandled
exceptions. Generally issues which occur deep within ArcGIS, and result in some
kind of un-anticipated failure in our custom .NET code. Even with a reasonable
amount of try/catch blocks, these exceptions do occur from time to time, and
they are exceptionally difficult to fix.

In this post, I’m going to tackle intercepting the unhandled exception. Once
you’ve caught the exception and collected the information you need, there are
any number of ways to log the information – custom web services, Enterprise Library
Logging Block, Log4Net etc.
In a future post, I’ll cover some of these.

Catching “Unhandled” Exceptions
From the .NET side of
things there are two ways you can “catch” unhandled exceptions. I say “catch”
because you can’t actually catch them in the typical try/catch/finally sort of
scenario. At .NET 2.0 an unhandled exception will allways cause the application
to exit. While the CLR is shutting things down, it raises events which you
can provide handlers for.

1) AppDomain.UnhandledException Event
This is the king-kahuna, and the story should end right here. Basically, if an unhandled exception occurs in the AppDomain, the AppDomain.UnhandledException
Event gets raised. At
which time you can log whatever you want. Great – problem solved and this post
is over. Only from my testing, this just does not work within ArcMap. After some head scratching, I read this curious
little note in the docs on MSDN…

For certain application models, the UnhandledException event
can be preempted by other events if the unhandled exception occurs in the main
application thread.

No indication as to what other events these may be, and I’m not sure what’s
going on in ArcMap (maybe someone from ESRI can shed some light?) but the end result is that this
event never fires. Thus, we move on to…

2) Application.ThreadException
While somewhat limiting since it only responds to unhandled exceptions that are
on Windows.Forms threads Application.ThreadException
Event provides an opportunity to log the exception before the application exits. And it does work in ArcMap, so it’s part
of a solution.

Example Project
Since I figured this all out by
writing some “research” (read: hacker) code, I thought I’d share it – maybe someone else can
figure out how to get those other unhanded exceptions.

About the code – this is VB.NET, written for ArcGIS Desktop
9.2. It has a total of 5 commands, and an Extension. My goal was to find a way
to centrally handle these exceptions – specifically in my extension.

The first command I created was the NotHandledCommand – which simply throws
an exception in the on_click event. This was my baseline to see if I could catch
this from my extension. The answer is no – you can’t catch an exception that
occurs in the command class itself. More interesting is that throwing an
exception in an ICommand does not cause a JIT window to appear. It looks like
ArcMap is eating the exception. Since I created my first command by
inheriting from BaseCommand, I created another command that directly implements
ICommand – and same thing. I can see why ESRI may want to do this (kepp ArcMap stable), but if you
are going to eat exceptions, please raise an event so developers
can know that an exception has occured.

Anyhow – to address this, we’re creating some new Command/Tool templates which will have
try/catch blocks with the correct logging code baked in (I’ll do a post about
creating custom visual studio templates too because this is super handy).

The next set of commands, ExceptionFormCommand and ExceptionFormTwoCommand
simply open up forms, which have a single button which throws an exception. As I
noted above, since this code is running on a System.Windows.Forms thread, the
exception is caught and the Application.ThreadException Event is raised. In the
extension. I created two commands simply to test it a little more. I then took
this a step further and created a dockable window (ExceptionDocWinCommand) which
also just raises an exception, and yes it also works. Then, to finish it off, I
created a user control (button that throws an exception), which I then put on
the dockable window – and yes – that worked too.

So – you can download the code below. Compile in Visual Studio 2005, run ArcMap and you’ll need to put the commands onto toolbars manually – they’re all in the “AAA Research” category.

And if anyone knows how to correctly
wire up the AppDomain.UnhandledException event, or another way to catch
unhandled exceptions please let me know.

Download Sample Code

With a dull title like that, I’ll be suprised if anyone reads this right off the bat! Anyhow -  I’ve been having some serious stability issues with my home wireless router – a Linksys WRT54G v6 – and thought I’d share what I ended up doing to solve the problem.

When researching the issue, I came across a number of forum posts which basically said the firmware from Linksys is unstable, and that the best solution was to flash the unit to an open source firmware – DD-WRT, based on OpenWRT (read more about it here). Here is an article about how it came to be that Linksys open sourced the firmware for the router (linux GPL license). And here’s the DD-WRT wiki.

At this point I was willing to buy a new router I decided to try this  – what the heck!

The actual process of switching from the Linksys firmware to the DD-WRT stuff was very simple – and there is a on-line recipe for this from Bitsum Technologies. I have to hand it to these guys – figuring out how to flash a linux OS into a 2Mb router through 3 steps must be complex, and they have really simplified it. It worked on the first try.

The only issue I had was getting the router newly flashed DD-WRT v23 SP2 micro router to get an IP address from Comcast via DHCP. The solution is very simple – just have the router copy the MAC address from your PC (Setup –> MAC Address Clone). Seems that Comcast will not dish out an IP to the embedded MAC address that the DD-WRT install ships with.

Once installed, you get a new management UI, and some additional features (so I’m told – I’m not enought of a networking guy to tell you exactly what other goodies have been added.)

Since installing this, wireless has been completely stable – so all is well.