Error handling and logging when developing ArcMap Add-Ins?

472
4
Jump to solution
12-13-2012 12:30 AM
FossiG_
New Contributor III
Hi,

1.) Error handling and logging
What's the best practice for error handling when developing ArcMap Add-Ins?

If an unhandled exception occurs, ArcMap just closes und presents an "Please inform ESRI about this problem"-dialog.

Is there any way to change this behaviour to get the originial error message and/or at least some rough hints where the code failed?
Or is there any kind of errorlog, which gives more informations for the developer?

2.) exception handling
What's the recommended way to handle exception? Is there any reluctance about Try..Catch on the most damageable spots?


Any hints or tips appreciated.

TIA,
Fossi
0 Kudos
1 Solution

Accepted Solutions
RichardWatson
Frequent Contributor
I do not believe that ArcMap provides any logging mechanism so you are left with providing your own.

There are many possibilities here including using built-in .NET tracing or various open source logging systems such as log4net.  Everyone has their favorite.

The key elements are logging which can be viewed via some type of trace viewer (such as Debug View from SysInternals), to a custom log file, and to the NT event log.  In the application I work on, we log critical errors to the NT event log, everything to the trace viewer, and a configurable level of logging to a log file.

So you code might look like:

try
{
   // application logic
}
catch (Exception e)
{
   // log e
   throw;
}

There is great debate with regards to whether or not you should eat exceptions that are not expected.  Run FxCop on your code you will see that the Microsoft Framework Guidelines do not recommend doing this.  You have to judge this for yourself.

View solution in original post

0 Kudos
4 Replies
RichardWatson
Frequent Contributor
I do not believe that ArcMap provides any logging mechanism so you are left with providing your own.

There are many possibilities here including using built-in .NET tracing or various open source logging systems such as log4net.  Everyone has their favorite.

The key elements are logging which can be viewed via some type of trace viewer (such as Debug View from SysInternals), to a custom log file, and to the NT event log.  In the application I work on, we log critical errors to the NT event log, everything to the trace viewer, and a configurable level of logging to a log file.

So you code might look like:

try
{
   // application logic
}
catch (Exception e)
{
   // log e
   throw;
}

There is great debate with regards to whether or not you should eat exceptions that are not expected.  Run FxCop on your code you will see that the Microsoft Framework Guidelines do not recommend doing this.  You have to judge this for yourself.
0 Kudos
FossiG_
New Contributor III
Hello Richard,

thanks for your reply. I will implement some logging and exception handling myself.

Anybody an idea about disabling this "Please inform ESRI about this problem"-dialog during development to get original error messages?

TIA,
Fossi
0 Kudos
FossiG_
New Contributor III
Ah, okay. Perhaps I misunderstood this dialog a little. This clarifies some things.

I will examine the crash dump files a little closers, perhaps they deliver some hints. Thank you!

Kind regards,
Fossi
0 Kudos