I'm working on a set of C# GP tools for use both in Desktop and Server 10.1.

The only soup-to-nuts treatment of writing geoprocessing tools in .NET appears to be Building a custom geoprocessing function tool. It does not cover what to do to handle exceptions.

I see a few possibilities and want feedback.

  1. In my tool's Execute() method, I can put my code in a try block, and in the catch I can augment the Messages by IGPMessages message.AddError(errorcode, errormessage).
  2. I can include among my tool's output parameters an error code parameter and an error message parameter. In the Execute() method's catch block, I populate these parameters if an exception occurs. Then they are available to the client in its Result object.
  3. do both.

(1) While this seems sensible for Desktop use, it seems to suffer a problem if in Server the GP service is configured not to return messages to the client.

(2) seems to suffer a problem in that I don't know of other tools that use this approach.

I want to make sure that the tool works correctly with the ArcGIS Silverlight API Geoprocessor task, which raises a Failed event if a task fails. What do I implement in .NET to make the task 'fail' correctly and gracefully?

  • it's taken awhile for my dust to settle on this one. It is now clear to me that the GP framework is such that it is best to use AddError(), a Desktop or Web API client will behave as expected. However, for a variety of reasons I've found Kirk's suggestion to also be useful. In general at 10.1, as a way to outfox the publishing wizard's 'helpful' Analyze step, I've found it important for my tools to take only simple text inputs and return text outputs. Doing this, one can make the return type include whatever one wants, including an error message if you like. – MC5 Apr 11 '13 at 20:53

I think that you should always use the inbuilt IGPMessages message.AddError(errorcode, errormessage). It is the standard way of providing feedback and error message in the ArcObjects framework.

Using the second option is sort of a hack, and this error message won't appear in the standard cases, like running the tool in ArcGIS Desktop or python. In programming, whenever a standard convention exists, you should always try to use it.

You might be worried about GP services on ArcGIS server, but I say that, that is not your problem. What if there is an error in one of the standard GP tools in such a GP service?

If the ArcGIS Server Administrator/Publisher does not want to expose the messages/errors to the end use, that is his/her headache. They decided to forsake the feedback from the GP service for some specific reason, and your tool should respect that.

| improve this answer | |

You might consider having the GP tool return a single string type. The string would be a json serialized representation of an object that includes a Error property. Populate the Error object in a top level try catch in your implementation of Execute. You might also consider making the Error property be an object that is analogous to Exception, with a nested InnerError to match up with InnerException. For handling json, I recommend using Json.NET instead of Esri's.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.