In your scenario I would have different handlers for both events. If an AbnormalOrderCanceled also needed to run the OrderCanceled Handlers, I would just publish the OrderCanceled event in AbnormalOrderCanceled Handler. An added benefit is that I have more control over whether to proceed to the next step. This quickly gets in to more elegant workflow solutions such as routing slips and sagas.

Some psuedo code: (this impl is beyond this post and more service bus specific. hopefully it is useful for some)

public class AbnormalOrderCanceledHandler : Handler
{
//pretty much all handlers get a reference back to the bus
IServiceBus _serviceBus;

AbnormalOrderCanceledHandler(IServiceBus serviceBus)
{
_serviceBus = serviceBus
}

public void Handle(AbnormalOrderCanceledMessage message)
{
// The abnormal parts of this event were handled successfully
// so move on to OrderCanceled
OrderCanceledMessage orderCancelledMessage = new OrderCanceledMessageBuilder(message);
_serviceBus.Publish(orderCancelledMessage);
}
}

Watch your check in RegisterClosedImpl. The code is too naive. Sometimes IsGenericType doesn’t work and you also need to check to see if it has generic parameters. Plus, you need to walk it up the base type tree. Plus, you need to consider if the open type is an abstract class instead of an interface. I had to patch some of this on SM tonight.

I will say though, that this is NOT a full equivalent to the SM conventional registration. Consider your effort with the Unity way versus the StructureMap Convention method. Advantage StructureMap;-)