Checking Null status on order

[pstrusi]

Hi,

I have a doubt in regards to check Null states on orders. In this forum are well known the samples: SampleOnOrderUpdate and SampleCancelOrder as simple codes showing us how to check and proceed.

protected override void OnBarUpdate()
        {
			// Submit an entry limit order if we currently don't have an entry order open
			if (entryOrder == null && Close[0] > Open[0])
			{
				/* The entryOrder object will take on a unique ID from our EnterLong()
				that we can use later for order identification purposes in the OnOrderUpdate() method. */
				entryOrder = EnterLong(1, "MyEntry");
			}
			
			/* If we have a long position and the current price is 4 ticks in profit, raise the stop-loss order to breakeven.
			We use (7 * (TickSize / 2)) to denote 4 ticks because of potential precision issues with doubles. Under certain
			conditions (4 * TickSize) could end up being 3.9999 instead of 4 if the TickSize was 1. Using our method of determining
			4 ticks helps cope with the precision issue if it does arise. */
			if (Position.MarketPosition == MarketPosition.Long && Close[0] >= Position.AvgPrice + (7 * (TickSize / 2)))
			{
				// Checks to see if our Stop Order has been submitted already
				if (stopOrder != null && stopOrder.StopPrice < Position.AvgPrice)
				{
					// Modifies stop-loss to breakeven
					stopOrder = ExitLongStop(0, true, stopOrder.Quantity, Position.AvgPrice, "MyStop", "MyEntry");
				}
			}
        }

        /// <summary>
        /// Called on each incoming order event
        /// </summary>
        protected override void OnOrderUpdate(IOrder order)
        {
			// Handle entry orders here. The entryOrder object allows us to identify that the order that is calling the OnOrderUpdate() method is the entry order.
			if (entryOrder != null && entryOrder == order)
			{	
				// Reset the entryOrder object to null if order was cancelled without any fill
				if (order.OrderState == OrderState.Cancelled && order.Filled == 0)
				{
					entryOrder = null;
				}
			}
        }
		
		/// <summary>
        /// Called on each incoming execution
        /// </summary>
        protected override void OnExecution(IExecution execution)
        {
			/* We advise monitoring OnExecution to trigger submission of stop/target orders instead of OnOrderUpdate() since OnExecution() is called after OnOrderUpdate()
			which ensures your strategy has received the execution which is used for internal signal tracking. */
			if (entryOrder != null && entryOrder == execution.Order)
			{
				if (execution.Order.OrderState == OrderState.Filled || execution.Order.OrderState == OrderState.PartFilled || (execution.Order.OrderState == OrderState.Cancelled && execution.Order.Filled > 0))
				{
					// Stop-Loss order 4 ticks below our entry price
					stopOrder 	= ExitLongStop(0, true, execution.Order.Filled, execution.Order.AvgFillPrice - 4 * TickSize, "MyStop", "MyEntry");
					
					// Target order 8 ticks above our entry price
					targetOrder = ExitLongLimit(0, true, execution.Order.Filled, execution.Order.AvgFillPrice + 8 * TickSize, "MyTarget", "MyEntry");
					
					// Resets the entryOrder object to null after the order has been filled
					if (execution.Order.OrderState != OrderState.PartFilled)
					{
						entryOrder 	= null;
					}
				}
			}
			
			// Reset our stop order and target orders' IOrder objects after our position is closed.
			if ((stopOrder != null && stopOrder == execution.Order) || (targetOrder != null && targetOrder == execution.Order))
			{
				if (execution.Order.OrderState == OrderState.Filled || execution.Order.OrderState == OrderState.PartFilled)
				{
					stopOrder = null;
					targetOrder = null;
				}
			}
		}

As you can see in the code, whenever OnBarUpdate triggers, there's this "Null" check:
" if (entryOrder == null && Close[0] > Open[0]) " so far it sounds normal, however in an interesting post, here: http://ninjatrader.com/support/forum...nmanaged+speed Brett as product manager, states:

"I would suggest that you only do any null checking inside of OnOrderUpdate(). If you see any iOrder checking in any of our sample code outside of OnOrderUpdate() to null please let me know and I will look into the code sample and make a correction however the rule of thumb is to only check order states in OnOrderUpdate(). Use this to set any flags needed for your OnBarUpdate()."

So, my doubt for maximum efficiency, speed and reliability: Is Brett right, and the sample, despite it works, it's not the best way cause potential issues ? Is there any sample with the Brett's way ?

Thanks in advance

[NinjaTrader_JessicaP]

Hello pstrusi, and thank you for your question. I will be happy to pass this along to the product management team so that we can update our samples and help guide accordingly. Would it be possible for you to send us direct links to pages that include null checking outside of OnOrderUpdate that you have observed?

[pstrusi]

Hello pstrusi, and thank you for your question. I will be happy to pass this along to the product management team so that we can update our samples and help guide accordingly. Would it be possible for you to send us direct links to pages that include null checking outside of OnOrderUpdate that you have observed?

Hi Jessica,

In this forum there're plenty of posts always leading to those well known samples, as I stated before. In this very link you'll find them again, go to the bottom and you'll find the OnOrderUpdate sample code for NT7 in a zip file.

http://ninjatrader.com/support/forum/showthread.php?t=7499

So my consult to you is still without a technical answer. Could you please may be pass it along to some other support fellow that is possible used to this matter ?

Looking forward,

Thanks in advance

[NinjaTrader_JessicaP]

I am a member of our NinjaScript team and am able to answer questions regarding null checks. I am following up with our product management team regarding the rational behind suggesting null checks be restricted to OnOrderUpdate, but I will be happy to answer any technical questions you have directly in the meantime.

Generally, the type of advice NinjaTrader_Brett gave has little to do with efficiency, speed, or reliability, as a null check is always guaranteed to be an O(C) operation (link text is publicly available). Instead, it is my belief that this suggestion was made to ensure the NinjaTrader platform was operating stably, and that our staff was not making suggestions that would lead to bugs in user code. Variables passed in to methods should generally be expected to be non-null, and orders in user code should be properly initialized. An object being unexpectedly null is often a bug, and so excessive null checking makes debugging more difficult.

In short while I am following up with our product management team to determine the exact reason this advice was given, generally, this is a coding quality recommendation in other applications.

If you would still prefer to deal with another tech please let me know and I will ask one of my colleagues to assist you. We will follow up and review our code samples after receiving a recommendation from the product management team.

[pstrusi]

Thanks Jessica for your technical answer, I'm satisfied, no need for more assistance to this question.

Please let me know in this post, if some new recommendation, sample..etc comes up from your team in regards to better, reliable or faster procedures.

Best regards

[NinjaTrader_Brett]

Thanks for bringing the doubt to our attention so we could take a second look. NinjaTrader 7 samples are pretty solid. Any check of iOrder from OnOrderUpdate or OnExecutionUpdate should be fine since those event will occur guaranteed after an order is generated. So there is no chance for it to be null unexpectedly.

NinjaTrader 8 works a little differently, but in principle good practices to maintain.