Proper use of IEditor (StartOperation / StopOperation)

2336
3
03-16-2011 09:47 AM
RiverTaig1
Occasional Contributor
I'm having some problems getting IEditor to behave in a stable manner.  If everything goes right in my code, then all is good, but if something unexpected happens (e.g. try to put too much data into a small field) it screws up the editor operation stack (I think) and then I basically need to restart ArcMap. It seems like I might get errors when I call Store, StartOperation, or even StopOperation. It kinda seems to vary. QUESTION: How can I rewrite the code below to keep things in a good state if something unexpected happens? Is there some key method like IsInEditOperation that I am missing as part of good defensive coding techniques.

Essentially my code looks like this:

bool hadToStartEditing = false;
if(editor.EditState == esriStateNotEditing)
{
  editor.StartEditing();
  hadToStartEditing = true;
}
editor.StartOperation();
//...More code to create a new feature & set it's shape / subype
// ...More code to set values on various fields (hopefully legal values, but perhaps not always)
editor.StopOperation();
if(hadToStartEditing)
{
  editor.StopEditing(True);
}
0 Kudos
3 Replies
SteveFang
New Contributor III
Try a "Try Catch" block to catch exception.  I like to also use a boolean variable to let me know if I am in an edit operation or not.  That way if my "Try Catch" encounters an exception then I can decided how to clean up the edit.  Ususally involves stopping the edit operation and not saving any changes.
0 Kudos
nikhilsastikar
New Contributor
Apart from Try Catch.. Finally block should also be implemented where in case of failure you can stop edit operation and edits.

Thanks
Nikhil
0 Kudos
AlexanderGray
Occasional Contributor III
I always do the try catch block as a matter of fact for every edit operation, I usually call abort operation in the catch block regardless of the error.  This way in the case of any unforeseen error, I stop the operation without messing up the call stack.  Any foreseen error, you are better off handling before it raises an error.  I never use abort operation in event listeners raised inside the operation, for that I just throw my own exception and the esri framework aborts the operation and pops up a message.
0 Kudos