Caught exceptions in AI Debug window

[Michiel]

Is there a way to not print caught exceptions to the debug window? I use them to indicate such things as failure to build a route (road plus buildings), where it's more convenient than trying to pass the error up the stack through return values, and it's slightly annoying when the screen turns red and knocks your useful info out of the available scroll space. There's always AILog.Error(e) if you want to print the stack trace for something you caught, after all.

[TrueBrain]

Can you give a code example? Because when you catch an error, it should not go up the tree anymore (so it shouldn't be in the AI Debug GUI). So an example for me to reproduce would be very useful

[Michiel]

... I'm not crazy, right? *goes off to check*
Nope, the voices say I'm fine

Code: Select all

class Test extends AIController {
	
	function Start() {
		AILog.Info("start");
		try {
			throw "ARGHBL!";
		} catch (e) {
			AILog.Info("Caught an exception: " + e);
		}
		
		AILog.Info("end");
	}
	
}

That results in the following output (in reverse):

start
Your script made an error: ARGHBL!

*FUNCTION [Start()] D:\Documents\Eclipse\workspace\ai\ai\michiel-test\main.nut line [6]

[this] INSTANCE
Caught an exception: ARGHBL!
end

What I'd love to have is something akin to Java's Throwable.printStackTrace() so you can get the red output during debugging without crashing your program, but "controlled" exceptions don't have to be shown. Though, since there's no exception object, I guess this might not be possible.

[TrueBrain]

This clearly is a bug on the side of SQ, or maybe not a bug, but 'a way they like implementing things' .. I won't bother you with the bad design choices Squirrel made (in my opinion that is ). The good news is that we are working hard to replace Squirrel with a language we designed ourself, which won't have such silliness. That said, I did try to find why SQ does what he does, but I gave up after a few minutes (total lack of documentation in SQ code).. so I am afraid for now you will have to just ignore the errors .. I hope that any time soon we can replace SQ and then you won't have this problem

Ps: tnx for the example, it made the problem very clear

[Zutty]

....The good news is that we are working hard to replace Squirrel with a language we designed ourself...

Err.... really? This makes me a little nervous. Are we going to have to completely re-write all our AIs from scratch when this happens?? If so, should we just freeze AI development until its done?

[TrueBrain]

....The good news is that we are working hard to replace Squirrel with a language we designed ourself...

Err.... really? This makes me a little nervous. Are we going to have to completely re-write all our AIs from scratch when this happens?? If so, should we just freeze AI development until its done?

Did I ever disappoint you? One moment I am your new hero, next moment you see all your hard work falling in a big void .. you are a silly person Hehe No, of course the language will be 90% compatible (we tend to remove the silliness But doubtful that you will notice it ). The only real hard change will be that we expect every command to end with a ';', but that is a simple action to perform (and one you might as well start doing now .

So really, don't worry, the main constrain is that current AIs keep on working .. and they will

[Michiel]

This clearly is a bug on the side of SQ, or maybe not a bug, but 'a way they like implementing things'

Hehe

.. I won't bother you with the bad design choices Squirrel made (in my opinion that is ). The good news is that we are working hard to replace Squirrel with a language we designed ourself, which won't have such silliness.

Oh, why did you decide to design your own language? Using something ready-made and well suited for embedding, like Lua or Python, could save you a lot of work and lower the learning curve for AI writers.

Ah, I just saw your next post. Yeah, that's a good reason to stick to something at least Squirrel-like.

Ps: tnx for the example, it made the problem very clear

You're quite welcome

[TrueBrain]

(..)
Oh, why did you decide to design your own language? Using something ready-made and well suited for embedding, like Lua or Python, could save you a lot of work and lower the learning curve for AI writers.
(..)

I guess I should make a single post soon explaining what is going on But to answer your question:

Squirrel is the 'bigger' brother of LUA. It is fully based on LUA, and extended to support classes (LUA doesn't, and you really don't want to program your AI without classes .. just imagine it :s).

Python on the other hand has a VERY bad 'embed' implementation. Not only does it leak memory (bah), also it is very huge (code-wise and memory-wise). And the worst part: the 'embed' part doesn't just work .. you need to patch the source before it does (by default you can't see which function called a callback to C++, nasty stuff).

I did, before starting with NoAI, a long survey trying to find the best language for the job. Squirrel was the only (!) one who was good enough. It is both small code-wise, as memory wise. Above that it supports just that what we need. Sadly enough, now more than a year in the usage of Squirrel, it turns out it took design choices which are weird and which gives us nasty problems. So .. I decided to investigate how hard it would be to create our own (and I was flamed by most NoAI devs for even thinking about it ). But it turns out it is really simple to do, and now 2000 lines later, it is nearing completion. It still has to be checked if it can really replace Squirrel, but so far it looks promising

Anyway, as I said, I should make this a new post ... I talk too much

[TrueBrain]

glx found the time to dive deep deep in the Squirrel code, and he found something! Fix is in SVN, in 18 hours a new binary will be here with the fix

[glx]

I must say something (before you start complaining ).
Squirrel handles runtime errors and exception thrown by your script in the same way. So a try-catch block in your script will catch the exceptions you thrown AND the runtime errors. It's not a bug, it's just how squirrel works.

[Zutty]

Did I ever disappoint you? One moment I am your new hero, next moment you see all your hard work falling in a big void .. you are a silly person Hehe No, of course the language will be 90% compatible (we tend to remove the silliness But doubtful that you will notice it ). The only real hard change will be that we expect every command to end with a ';', but that is a simple action to perform (and one you might as well start doing now .

So really, don't worry, the main constrain is that current AIs keep on working .. and they will

I should have learned to trust you by now!! Will stuff like meta-methods (_cmp(), _get(), _nexti(), etc...), tail-recursion, and higher-order functions (lamba functions) be supported? I have tried to take advantage of the "nice" features of Squirrel wherever I could.

[Roujin]

Just as a little info for the interested (Zutty..), you can follow the progress of the squirrel replacement here: http://hg.openttd.org:8000/users/noai/ml.hg/

[Michiel]

Anyway, as I said, I should make this a new post ... I talk too much

Not at all, was an interesting read

[Michiel]

glx found the time to dive deep deep in the Squirrel code, and he found something! Fix is in SVN, in 18 hours a new binary will be here with the fix

I must say something (before you start complaining ).
Squirrel handles runtime errors and exception thrown by your script in the same way. So a try-catch block in your script will catch the exceptions you thrown AND the runtime errors. It's not a bug, it's just how squirrel works.

1. Awesome
2. So, if I understand correctly: caught exceptions are no longer printed, and my catch block will catch everything including runtime errors? Sounds fine by me Just check to see what you caught, and if it's not something you know how to handle, just rethrow it.

Edit: tried it, love it

[Michiel]

I'm guessing "no" , but is there any way to get a stack trace for a caught exception? Rethrowing it seems to replace the original stack trace, which makes it almost impossible to debug runtime errors without ripping out all my try/catch blocks :-/

[glx]

There should be a way. I'll look into that.

Edit: I did some research and it's possible to get the stack directly in your script using getstackinfos() in a function like this

Code: Select all

function PrintStack() {
  local i = 2; // 0 is getstackinfos, 1 is PrintStack()
  while (1) {
    local stack = getstackinfos(i);
    if (stack == null) break;
    AILog.Error("*FUNCTION [" + stack.func + "()] " + stack.src + " [" + stack.line + "]");
    foreach(idx, val in stack.locals) {
      AILog.Error("[" + idx + "] " + val);
    }
    i = i + 1;
  }
}

Edit2: looked like a good idea but it doesn't tell where the error was as the stack related to the error is cleaned when entering in the catch. So the only way I can see to get the stack trace is to revert the change I made to not show it for handled exception.

[Michiel]

I'm afraid so :-/
I've already gone and found the change in squirrel.cpp and locally changed the notifyallexceptions line back to SQTrue, because you really need the stack traces for debugging.

[glx]

I finally reverted the change. But I added a notifyallexceptions() function to enable/disable stack trace displaying for caught exceptions.