running a program with the above line of code is causing my program to crash -- if I have a symbol in the dataset that has no data for the specified range on which I'm running a backtest ( for example, 1/1/2005 - 1/1/2007 ).

I think I can "fix" the problem by wrapping the line in a Try / Catch statement (haven't tried yet, yes pun intended), but don't you think the statement should figure out a way to return more gracefully -- maybe setting Bars object to null or something other than crashing the code?

Here is the error message:

Do you mean Wealth-Lab is crashing or your script is generating a runtime error?

I think a runtime error is very appropriate when you ask to load a symbol that has no data for the range. Your script needs to expect and handle that.

i mean runtime error but i disagree that wealth-lab generating a run time error is appropriate in this instance.

we don't know how many bars (if any) are available for a symbol before loading it. if there was a standard way for the function to return something that could be tested for (such as a Bars object = null in this instance) it seems to me that would make a lot more sense.

QUOTE:
Your script needs to expect and handle that.

correct me if i'm wrong, but every script that utilized Set Context would need to "expect and handle" the possibility of no data, since any symbol for which the context is being "set" could conceivably have no data for the specified period.

my questions are: 1) do you know any other ways (other than Try / Catch) to handle that possibility
2) are you suggesting that every call to Set Context should be wrapped in a try statement -- if so, i've never seen that coding approach in any sample code that i have viewed

assuming i'm thinking about this right, it seems like it would be a lot easier to have the following:

CODE:
Please log in to see this code.

In other words:

Currently:
A runtime error occurs accessing a null Bars object via SetContext. (The error can be caught and ignored.)

You prefer:
A runtime error if the programmer forgets to logically check for a non-null Bars object. (The error can be avoided by conditionally checking for a null Bars object.)


I'm having trouble determining how your solution adds value.

i think wrapping code in the Try statements is a bit awkward.

my solution isn't meant to be a solution, instead it's 1) a question on what is the appropriate way to handle this and 2) a statement / suggestion that since this can happen to any symbol, shouldn't all the sample code that uses Set Context be wrapped the same way.

Everybody likes to do things a little differently, but this is the current design, and it's working properly. There's a barrel of bigger fish (real bugs) to target right now, but I certainly don't see a problem with updating the QuickRef for SetContext with some verbage about what to expect for a null Bars condition.

Edit -
Just re-read this. Are you saying that Bars is not being set to null following the synch? If that's the case, then I do agree with you!