A pitfall in Flexsim coding

I hope I can share something that can be avoided and improved in future in the Flexsim coding.

In Flexsim script, when you use the commands rank, setnodenum, setnodestr, set ect., if the node does not exists, the rest of the coding below the line of setnodenum will be quietly ignored. I am not sure if this is a designed feature but it is a very annoying, making debugging very hard if you are not aware of that. If you want to test this, try following lines in the script window:

pd(1);pr();
 setnodenum(NULL,1);
pd(2);pr();

if you execute the code, the line 3 won't be executed without giving any error message (I do see something in System console. But first it is not an error message; and second so many messages are printed out in System console if it is open and I have no idea what they mean.). This is just an illustration. If you have hundreds lines of code, it would be hard to identify the problem since you may notice something else is wrong without knowing that it is the line of setting node number causing the rest of coding not executed. I know we could add a line if(objectexist(obj)) before line 2 to test if the node is exist or not. But I wonder how many people are using objectexist() every time when they need to use these node setting commands. Besides, if it is the rule that objectexist() should be used before these node setting commands, why not just put objectexist into these commands and give a clear message if the node does not exists?

Anyway, I wonder if there are other commands causing such problems. And I do not think the current way of handling these commands (quietly ignoring the rest of lines) is the right way.

By the way, I am using Flexsim 4.32.

Hi Alan,
I saw that too, and I have to say that searching this kind of coding errors is quite time consuming.

Anyway, befor you use any tasksequences or node manipulations (destroy, setnodenum etc.) you should check if all the objects and nodes exist. It´s a little bit more work to check, but in the end it can save a lot of time.

Maybe the debugger should be improved, at least it should give a message in the system console that the trigger could not be executed... (like when there is a missing label)

Alan, the Flexscript parser caught an exception in your code due to a bad pointer. This kept your program from locking up. It instead exited gracefully from the function call that had the problem and executed other code instead (which printed a cryptic message to the system console.)

It is up to a coder if they want to be sure their pointer is good to put their own checks in. Doing it on each call to a function would be unnecessarily slow. You only need one check usually before multiple calls using that pointer.

You are right that the system console shouldn't be so cluttered though and that the error messages it gives aren't particularly helpful right now if you aren't familiar with what they mean.

"double parsertwo::evaluate(linkedlist * x, linkedlist * theinstance, linkedlist * theclass, byteblock * abovelevelbyteblock,linkedlist * associated, void * data, double * flexscript_iterator, _callpoint * callpoint, linkedlist *ignoredisable)
x: /0/setnodenum PTR 160359552"

That shows where the exception was thrown, in the parser's evaluate() function. It also says "x:" to tell me that it was an exception and listed what call within the function died: "setnodenum".

You can read more about try/catch exception handling online if you would like to understand better why programs work this way. http://msdn.microsoft.com/en-us/libr...bc(VS.80).aspx

Hi Phil,

Thanks for the explanation and the link. I guess it is the trade-off of the efficiency between the programmers and the programs. In many times, I may not want spend one or two days of my time for debugging such errors to trade several minutes of speed improvement in the simulation program. Besides, the computer speed are faster and faster and the compiler are more and more efficient. I think It would be more important to improve the programmer's efficiency more and more. It is no good for Flexsim itself if its users have such frustrated experience. I wonder how much extra computer time will be used by checking if a pointer is a NULL or not.

But if the Flexsim is determined working that way, it better to warn people about that instead of quietly printing out a confusing message in a hidden window. Flexsim is a very good software. However, it is far less than perfect.

Perhaps a global option should be used to turn on or off the object pointer checking internally in Flexsim? Only when the simulation speed becomes a issue, we will turn it off? If doing this way, we have one more way to know if we forget checking object pointer in our code by turning the option on or off, right?

Anthony added this issue to the development list for 4.5: to get rid of the useless system console prints, change the exception prints to be more readable, and to have the system console automatically open when an exception is thrown (with a checkbox preference to disable it from automatically appearing).

Thanks, Phil.

Alan,

Instead of creating a new post to say thanks (Which alerts the rest of us to come and see what was posted). Just click the thanks button at the bottom of his post. This does three things very effectively: 1) It increases his reputation and VB score; which the above post doesn't do. 2) It keeps the rest of us from wasting out time to come and view a post that has no real significant meaning to the rest of us. 3) It effectively lets Phil know that you appreciated his post.

Please don't take this harshly, I'm sure Phil appreciates the thanks and the rest of us want to encourage that sort of thing. I just felt that this was a good time to let everyone know that the thanks button was there and that if you had been thanking me, then I would appreciate that sort of thanks over a posted thanks.

Thanks for the participation,
Brandon

Well, I guess you have your point and I will take your suggestion. I guess I need sometime to get used to that Thanks button. :-)

Alan