[GIS] ArcGIS 10 add-in: Top-level exception handling

add-inarcgis-10.0arcobjectscnet

The ArcGIS 10 add-in I'm working on is pretty simple — just a tool control and a dockable window. I'm handling the specific exceptions I anticipate occuring at the source and throwing everything else, but what is the best practice for handling those unexpected exceptions in the add-in framework?

I'm currently just doing a catch (System.Exception ex) and showing it in a MessageBox in every method that doesn't have a higher-level method I could handle it in, but this doesn't seem like the best practice (and of course, FxCop is whining about it).

Is there any facility in the ArcGIS 10 add-in framework for a top-level exception handler to be hooked up, for example to the Application.ThreadException or AppDomain.UnhandledException events?

Seeing as add-ins are just class libraries and not applications with no access to the underlying application's startup code (from what I gather, those events have to be hooked up very early in the startup process), my guess is no, but I thought I'd ask if any experts out there had any suggestions on how "unexpected" exceptions should be handled in add-ins.

Best Answer

As far as I can tell you are implementing the error handling that ESRI is currently putting out there as best practice. If you were to grab a hold of the application's (ArcMap) unhandled exceptions you could potentially be then displaying messages about errors that were not part of your AddIn. Most of the AddIns you write are probably going to be buttons and those really only have two major routes that unexpected errors would be caught and displayed (onClick and onUpdate).

Just remember to use the 'throw' instead of 'throw ex'. There is a minute difference, but it results in retaining the error's lineage as it bubbles up from called functions.

Related Solutions

[GIS] ArcGIS 10 add-in: ComboBox add-in component focus issue

In your code that you gave as an example. In my testing this worked for me.

new Thread(() =>
{
   MessageBox.Show(String.Format("The value '{0}' is not an integer!", currentValue));
}).Start();

Edit To incorporate the great comments, and as Petr pointed out that this way may be dangerous here is the other way of doing this as well:

SynchronizationContext.Current.Post(_ => MessageBox.Show("Message"), null);

Thanks to Kirk and Petr for this!

[GIS] ESRI ArcMap Add-in Config.esriaddinx

First off, I have not tried using Config.esriaddinx for this purpose, but I wouldn't recommend it. It is meant for the configuration of the add-in itself, not necessarily user data, and you probably don't want to mix the two.

It has been a while since I've dealt with this myself so I may be a little fuzzy on the details, but there are multiple issues with using configuration files in ArcGIS add-ins: ArcMap Add-in with app.settings not recognizing app.config changes?

In particular, the directory the add-in is extracted to is overwritten each time the application is started, so you can't really persist changes to settings there. If your settings never change or only change with each new version of your add-in then this is probably not a concern.

If, however, you want to make your add-in configurable by the end user then you need to store the user-configurable information elsewhere so they aren't overwritten. I would suggest using the user's Application Data folder, whose path you can determine programmatically like so:

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)

I would also suggest putting it in a subfolder named after your add-in. But essentially you would be loading from and saving to a file in that location instead of reading settings from your add-in's Settings class or the configuration file in the add-in's directory. If you want to use .NET configuration for this then I suggest reading up on Application Settings and ConfigurationManager.

The other problem I have had is with using custom configuration sections when using .NET configuration. Using Assembly.LoadFrom and handling the AssemblyResolve event was the solution to that particular problem, although in that case I ended up not using .NET configuration for that and other reasons.

Depending on the complexity of your configuration scenario, you could, like I did, eschew using the .NET configuration system entirely and instead use some other method of reading and writing configuration information. I ended up using SerializableAttribute-marked classes or classes which implemented IXmlSerializable for this purpose in one of the more complex add-ins I created which included user-configurable settings such as lists of layers, connection settings, etc. I would recommend reading Object Serialization in .NET, Introducing XML Serialization and How to Implement IXmlSerializable Correctly if you are interested in that approach.

It sounds like yours is along the same lines so it is up to you, but I found the XML serialization approach to be preferable to .NET configuration for all but the simplest of configuration scenarios (simple data types, no hierarchies/collections).

Best Answer

Related Solutions

[GIS] ArcGIS 10 add-in: ComboBox add-in component focus issue

[GIS] ESRI ArcMap Add-in Config.esriaddinx

Related Question