Scott, This is a known behavior. It is by design, so I won't even call it a bug, although it sure can be misleading, as you've found out! It's an excellent question & ought to go under some sort of FAQ, in the new U2UG Wiki maybe. Here's the question, with an answer below:
> Here is a weird UV error condition that I just spent way too long debugging: > > >CT BP SB > > SB > 0001 X = "" > 0002 IF X EQ "" THEN X = Y > 0003 PRINT "ONE" > 0004 PRINT "TWO" > 0005 PRINT "THREE" > 0006 PRINT X > 0007 Y = "A" > > >RUN BP SB > > ONE > TWO > THREE > Program "SB": Line 6, Variable "X" previously undefined. Empty string used. > > Why does the run-time error happen in line 6 instead of line 2? In an assignment like X = Y, all that happens is that X is pointed to the same address in the user's memory that Y is at. This is really nice when Y is a very long string. Rather than duplicating the string in memory, both X & Y point to the same spot until one of them changes. At that point there are 2 strings. The problem here is that Y has never been assigned. So X is made to point to Y, which is just fine, until X actually gets used. At that point it tries to read what is in X (i.e., what is in Y) and yields an "Undefined variable" error. Solutions: * Correctly initialize Y. Obviously, Y should be initialized before it is used in "X = Y". * If this is a subroutine where Y is an input argument that you have no control over, test it using ASSIGNED(Y) or UNASSIGNED(Y) functions before relying on it. * When debugging, look back to how the variable was assigned, realizing that simple assignments like X=Y mean the problem is with Y, not X. A Terrible, Horrible, Disgusting, but Common (Non)Solution: Do NOT BLINDLY INITIALIZE ALL VARIABLES at the top of a program. Initialize them intelligently exactly when needed, limiting their scope. I see this so often! I think it is because of programmers who are used to other languages with strongly typed variables that need to be DECLAREd at the top of the routine have an uncontrollable urge to declare variables in MV basic, but the closest they can come is to indiscriminately add Y='' or Y=0 to initialization. This actually HIDES BUGS! It is better to have the runtime bug that shows up the error, than have it run wrong silently. Suppose in the little test demo program below "Y=0" was indiscriminately inserted at line 1. Maybe Y should be zero, maybe not. But we'd never see the runtime error that points out the bad logic. The bad logic remains, running silently in the background, the latent bug corrupting processing and data. Learn to routinely monitor uv/errlog for runtime errors like this that might slip by your users. You can catch these latent bugs and fix them at their source, rather than waiting for users to complain about bad data and wondering how it got that way. I've promised to add a Wiki article on monitoring uv/errlog, including some programs to do so. Chuck Stevenson ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
