Skip Invalid Element Generation Using Failure API

We already took a couple of looks at the Failure API in the past, e.g.:

• Failure API
• Failure API Take Two
• Failure Rollback

Here is a slightly more convoluted situation that motivates revisiting the topic from a new angle, raised and solved by Stephen Faust of Revolution Design, Inc. together with Arnošt Löbel of the Revit API development team, who also invested significant time and research in the issue:

Question: I am generating some floor objects from rooms in a project. In certain cases the sketch is not valid because of some oddities in the rooms. This is OK if I can just delete or not create the floors and hopefully not show a dialogue to the user. Without any failure handling it gives the user the 'can't make extrusion' error, but you can hit delete elements and be on your way. I thought I could do this with a failures preprocessor, but it doesn't seem to be working the way I hoped. Here is the functional part of my class that inherits IFailuresPreProcessor:

  IList<FailureMessageAccessor> fmas
    = failuresAccessor.GetFailureMessages();
 
  if( fmas.Count == 0 )
  { return FailureProcessingResult.Continue; }
 
  foreach( FailureMessageAccessor fma in fmas )
  { failuresAccessor.ResolveFailure( fma ); }
 
  return FailureProcessingResult.ProceedWithCommit;

When I use this with the transaction, it still gives me an error dialog, only this time it shows (Deleted) next to all of the elements. The only thing I can do is cancel, which is actually worse, because then you don't get any of the floors. What am I doing wrong here? What do I need to do to just handle the dialog and tell it to remove those floors that aren't valid?

Answer: What you probably need to do is to set the resolution on each failure.

There are also some checks required to avoid attempting to resolve a failure that may not be resolved (anymore).

I suggest the following starting point for an approach, plus further experimenting with it:

• Test if invalid elements (floors) can actually be deleted by calling FailuresAccessors.IsElementsDeletionPermitted.
• Possibly, for each failure, it may be tested if its resolution by deleting the invalid elements is permitted. The method to do so is FailuresAccessors.IsFailureResolutionPermitted taking a FailureResolutionType.DeleteElements argument.
• Assuming you can, failures should be resolved by FailuresAccessors.ResolveFailures.
• I am also guessing that before returning ProceedWitCommit, FailuresAccessors.IsTransactionBeingCommitted is tested.
• Return ProceedWitCommit.

Response: Thanks for the tips.

Here is what I ended up doing that seems to be working:

  if( failuresAccessor.GetTransactionName()
    == "Create Temporary Roofs" )
  {
    IList<FailureMessageAccessor> fmas
      = failuresAccessor.GetFailureMessages();
 
    if( fmas.Count == 0 )
    { return FailureProcessingResult.Continue; }
 
    foreach( FailureMessageAccessor fma in fmas )
    {
      FailureSeverity s = fma.GetSeverity();
      if( s == FailureSeverity.Warning )
      { failuresAccessor.DeleteWarning( fma ); }
      else if( s == FailureSeverity.Error )
      {
        if( failuresAccessor
          .IsElementsDeletionPermitted(
            fma.GetFailingElementIds().ToList() ) )
        {
          failuresAccessor.DeleteElements(
            fma.GetFailingElementIds().ToList() );
        }
        failuresAccessor.ResolveFailure( fma );
      }
    }
    return FailureProcessingResult.ProceedWithCommit;
  }
  else
  { return FailureProcessingResult.Continue; }

Basically I separated out warnings from errors. Then warnings can be deleted, errors can be processed and delete elements can be directly called for specific elements causing the error.