Error messages without a source

#1 Most of these are the runtime errors you get when you try to call a method on a non-existent object. For example, type something like this into the console:
%bad = 0;
%bad.getName();

It will produce the same kind of error.

#2 Thanks, Jeff.

That part I comprehend. The part that's getting me is that usually, the error is prefaced by something like "player.cs line 234:", so I know just where the offending code is. Here, it's just " (0)". What does that mean?

#3 These are tough to debug, I admit. Here's what I usually do:

--note the name of the function trying to be called by a "0" object
--use Torsion's "find in files" capability to list all lines of TorqueScript that contain that line (hopefully it's not a -huge- amount, but sometimes it is)
--set breakpoints at each of these.
--run my program under Torsion, and each time a breakpoint is triggered, use the "Watch" capability to see what the value of the objectId actually is. If it's already 0, then you're pretty certain you've found the spot.
----make a decision if I should go ahead and clear this breakpoint (normally, if it's stock code, I do, code bugs are normally in code I've written, although not always).

Don't forget that you can use line by line debugging, as well as step in/step out functionality to pay closer attention to what your functions are doing.

#4 Initially I thought the lack of line numbers was just a compile-time vs. runtime issue, but apparently similar runtime errors do produce line numbers. (0) may be indicating that the code lacks a file source, such as the case of directly entering it into the console. Are your running any on-the-fly code via an "eval" call or something like that?

#5 @Stephen, good ideas, thanks. Any idea why this happens, sometimes, what it means?

@Jeff, nope, it's not not that. I've periodically seen this happen, but before I also had messages referencing line numbers, and when I took care of those, these weird ones went away. The problem this time was that this was all I got.

#6 It basically means that you are trying to access methods on an object that doesn't exist.

It's either:

a) you are using code before it should be--the reference has never been set to anything
b) the object that you are trying to access has been removed from the simulation, but you still have an objectID stored in a dynamic field. For example, if (hypothetical here) you do something like this:

function SomeWeapon::onFire(%this)
{
   %projectile = new Projectile () { ....};
   %this.projectile = %projectile; // this line stores a reference to the projectile object
}

and then elsewhere you try to use the reference:

function SomeWeapon::checkProjectile(%this)
{
    %className = %this.projectile.getClassName();
    echo(%className);
}

The function SomeWeapon::checkProjectile() will work fine, until the projectile collides with something. Since the stock code destroys a projectile when it collides with things, the projectile object will be removed from the simulation, but you have stored a reference to it--and that reference won't be updated directly.

The best practice is to make sure that you keep track of all your references, and clean them up when needed --or even better, make sure your execution flow logic is tight enough that you never call SomeWeapon::checkProjectile() unless the projectile is guaranteed to exist.

Unfortunately, this is pretty hard to do--takes some very tight code. What most people will do to remove the error itself (but not the design flaw) is use of the isObject(%reference) call:

function SomeWeapon::checkProjectile(%this)
{
    if ( isObject(%this.projectile) )
    {
      %className = %this.projectile.getClassName();
      echo(%className);
    }
}

As I mentioned though, this is really a "hack" fix, that doesn't fix the problem, only the symptom.

If the projectile doesn't exist in the game world, the call does nothing--but still has the performance overhead of doing the call itself, and having to do the object validation, etc.

#7 I was a little curious about why you are getting "" errors rather than the usual error form you get when referencing methods of non-existent object, so I did a little research. If you search the code using "" you can pretty easily find that it comes from codeBlock.cpp. Apparently you get the "" text when the error occurs inside a code-block without a filename reference.

I'm not exactly sure the entire scope of situations where code blocks are running without a filename reference, but it would include typed in console code, eval calls, and C++ calls to Con::evaluate(). These evaluate() calls are used in the gui code a bit and also in the action-map bindCmd calls, I think. It looks like you have a chunk of code executing indirectly via something like an Con::evaluate().

#8 @Stephen: Thanks. Yeah, I'm learning about tight code these days! The hard way, as usual.

@Jeff: That makes sense. In my case it must be coming from the source--that does make sense.

Naturally, the errors have disappeared, and I hadn't changed anything. Magic!