Strategy accessing external symbol in Strategy Monitor causes exception
Author: kazuna
Creation Date: 2/21/2013 1:07 PM
profile picture

kazuna

#1
{DAILY} DataSet contains Daily scale symbols "SPY" and ".VIX".

Add the strategy in Strategy Monitor with the following settings:
Data: {DAILY}
Range: All Data
Scale: Daily

Then "Run this Strategy now" while market opens and observe the debug output in DebugView.
http://technet.microsoft.com/en-us/sysinternals/bb896647

You will see:
QUOTE:
Exception! [System.NullReferenceException: Object reference not set to an instance of an object.
at WealthLab.Strategies.MyStrategy.Main()
at WealthLab.Strategies.MyStrategy.Execute()]

If you run this strategy in Strategy Window, it runs just fine.
Interestingly, it runs fine in Strategy Monitor once the market closes.

Why does the strategy running in Strategy Monitor cause an exception?
Why is it only when the market is open?
"PrintDebug" doesn't work when running in Strategy Monitor. Why?

By the way, if I replace the code accessing external symbol from:
CODE:
Please log in to see this code.
to:
CODE:
Please log in to see this code.
or
CODE:
Please log in to see this code.
then the exception seems disappears.

CODE:
Please log in to see this code.
profile picture

Eugene

#2
Yes, it's a known bug:

Open Issues > (6.4) (98370) A GetExternalSymbol overload failure in Strategy Monitor
profile picture

kazuna

#3
I should have checked it out at the first place. Thanks Eugene!
profile picture

kazuna

#4
By the way, "PrintDebug" doesn't work when running in Strategy Monitor is also a known issue?
profile picture

Eugene

#5
PrintDebug, cosmetic chart methods (drawing, accessing ChartPanes etc) intentionally do not work in the SM.
profile picture

kazuna

#6
And even exception dialog won't pop up.

It took a bit for me to figure out that PrintDebug won't run in the SM and there was an exception occurring while executing.
I guess user guide would be nice to explicitly mention about this limitation.
profile picture

Eugene

#7
Exceptions, including those generated by the data provider, are to be found under the SM's "Action" column.
profile picture

kazuna

#8
It's been five years and the issue is no longer listed on Open Issues page but I'm still getting the issue on the latest WLP 6.9.19.
profile picture

Eugene

#9
As of WLP v6.8, GetExternalSymbol() with the dataSetName overload no longer improperly returns a null object in the Strategy Monitor. This bug #98370 was fixed. Test proves that this code runs fine on EOD data (on a symbol in a DataSet different from the specified) in WLD 6.9.15:

CODE:
Please log in to see this code.
profile picture

kazuna

#10
I changed the code slightly and this one causes an exception only when it runs in Strategy Monitor.

If I change SYMBOL to ".VIX", the exception goes away.
If I comment out the line of "if (Bars.Symbol.Equals(SYMBOL))", the exception goes away.

Does it make any sense?

CODE:
Please log in to see this code.
profile picture

Eugene

#11
No, I don't get an exception in WLD 6.9.15 either. It doesn't matter if the DataSet the system runs on belong to same or different data provider (e.g. Yahoo/Cryptocompare), external symbol being valid or invalid etc.
profile picture

kazuna

#12
The DataSet has to be exactly:
DataSet Name: DAILY
Scale: Daily
Range: All Data
Symbols: .VIX SPY

Could you try the DataSet containing just these two symbols?
profile picture

Eugene

#13
In my test I did name it "DAILY" but it's about grasping at straws. I neither work with WLP nor .VIX is a valid symbol outside Fidelity's symbol universe. However, the data range was set to 10 years and I can imagine this to make some difference. If so, I'm glad we've got workaround: choose a different data loading range and load less data.
profile picture

kazuna

#14
Did you set DataSet "DAILY" not Symbol as Source Data?

Even if I replace .VIX with AAPL in the DataSet, the exception still occurs.
I also tried different data range and load less data but it doesn't help at all.

However, I think I found a pattern in the problem.

Here is the combinations that cause the exception:

Symbols: AAPL SPY
SYMBOL = "SPY"

Symbols: SPY XLE XOP
SYMBOL = "XLE"

Symbols: SPY XLE XOP
SYMBOL = "XOP"

Here is the combinations that DOESN'T cause the exception:

Symbols: AAPL SPY
SYMBOL = "AAPL"

Symbols: SPY XLE XOP
SYMBOL = "SPY"

So apparently not calling GetExternalSymbol for the first symbol in the alphabetical order causes the subsequent calls to GetExternalSymbol for the other symbols to return NULL.

In fact, the following single line below fixes the exception.
CODE:
Please log in to see this code.


Does this mean the external symbol has to be all initialized once at the first run for the first symbol?
profile picture

Eugene

#15
QUOTE:
Did you set DataSet "DAILY" not Symbol as Source Data?

I ran it both ways: on different DataSets and making "DAILY" the primary DataSet (which makes less sense). Never any problem in WLD nor any record in the DebugView app. I get no error even if the DataSet and/or symbols do not exist.

It's clear to me that I will not succeed in reproducing this exception in WLD 6.9.15 which is thrown on your end. Please use the workaround described in your post #1 (i.e. calling the GetExternalSymbol overload w/o the DataSet name) or in post #14. Whatever works for you is fine with me. Thanks.
profile picture

kazuna

#16
I'm fine using the workaround for the time being but I'm still anxious about the the root cause of the problem.
Isn't my finding sufficient to figure out the problem by inspecting the source code around?
profile picture

Eugene

#17
As a third party company we (MS123 LLC) we have never had access to the Wealth-Lab source code and so we cannot track the issue down to a line of code. And I can't say there's "appetite" from the contractor now for resolving potential issues like this which don't affect trading and may have a Low to Medium impact. Especially when they have a workaround and/or have trouble being reproduced. Sorry.
This website uses cookies to improve your experience. We'll assume you're ok with that, but you can opt-out if you wish (Read more).